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