Re: condvar

"Axel Dörfler" <[email protected]>
Newsgroups gmane.os.openbeos.kernel.devel
Message-ID <38593867093-BeMail@zon>
Philippe Houdoin <[email protected]> wrote:
> > 3) (the clean version) add a new pair of system calls: switch_sem()
> > and switch_sem_etc() (other naming suggestions are welcome). 
> > Applications using these functions would not run on R5 or Zeta 
> > anymore.
> Cleaness was (most of the time) the BeOS way. IMHO, better to kept 
> Haiku on the
> same road. New syscalls is great. It's a > R1 feature, so it make 
> sense to
> expand the kernel API anyway... and still keep binary compatibility 
> with R5
> apps.

As it's already implemented, we might as well make it public for R1. 
Anyway, I'll add the functions to the public OS.h header, and add a 
syscall for them - we can then still decide what to do when we actually 
do release something; until then it's private anyway :-)

> François added:
> > Btw, there is a big issue with the current pthread implementation 
> > as
> > well as yours: it doesn't handle the STATIC initializers...
[...]
> > #define PTHREAD_MUTEX_INITIALIZER	NULL

Ours doesn't do that, although it doesn't work the way it's done now 
either :)
I am well aware of that, but thanks for the note anyway.

[...]
> It's a ticking bomb :-(, because it assert that we never destroy or 
> unlock a
> mutex without having locked *once* at least. Plus the performance 
> hit, also.

One could easily add the semaphore construction to all functions; but 
in any way, it's not very clean. However, since C does not know the 
concept of global initializers, there is little we can do about it; it 
will look similar to your solution.
BTW the POSIX specs only talk about pthread_mutex_lock() for lazy 
initialization of a static lock, and since mutexes are not like 
semaphores, this should be no problem.

> - Philippe, back online (have I mentioned that I hates my ISP?)
> with huge stack of pending emails...

Nice to have you back anyway :-)
Will you make it to BeGeistert this time? (I expect François to be 
there anyway :-))

Bye,
   Axel.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.