Date: Mon, 16 Sep 2002 21:32:03 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Alfred Perlstein <bright@mu.org> Cc: standards@freebsd.org Subject: Re: sem_* API Message-ID: <Pine.GSO.4.10.10209162113010.22806-100000@pcnet1.pcnet.com> In-Reply-To: <20020917010939.GE86737@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[ switching to -standards if that's OK ] On Mon, 16 Sep 2002, Alfred Perlstein wrote: > * Daniel Eischen <eischen@pcnet1.pcnet.com> [020916 16:41] wrote: > > On Mon, 16 Sep 2002, Alfred Perlstein wrote: > > > > > * Alfred Perlstein <bright@mu.org> [020916 16:08] wrote: > > > > I got sort of bored so I wrote a kernel version of the POSIX sem_* > > > > functions so that we can support sem_open() and sem_init() when 'pshared' > > > > is set to true. Basically this is posix semaphores that can be used > > > > between processes. > > > > > > > > I haven't tested it as of yet (but I will be soon), here's the delta > > > > for it. > > > > > > > > Does anyone know a test suite for this API? > > > > > > Of course actually including the _new_ files might help, > > > the diff can be pulled from here: > > > > > > http://people.freebsd.org/~alfred/deltas/sem.diff.gz > > > > I'll only comment on the pthread portion. > > > > Please put objects in the beginning of the file before functions > > are implemented (named_sems and named_sems_mtx are declared > > between functions) to keep in style with the rest of the thread > > code. > > > > If those objects (named_sems and named_sems_mtx) need to be external > > then you must precede them with underscores. I think they can be > > static though. > > > > If you use mutexes internally (that the application doesn't know > > about) then you must use the _pthread_mutex_* variants (single > > underscore). The library treats these differently so that the > > thread will not be canceled or have a signal handler installed > > while holding one of these. > > Thank you, I've applied all your suggested changes to my local > tree. Yes, the structures are local, I neglected to 'staticize' > them. > > I've also applied the delta to libc_r since Julian said I would > need to do that to test it for now. Right. > Does it make sense for these to actually be in libc? This is > because they can be used to inter-process syncronization, not > just between threads... Well, Solaris has them in librt (real-time) and not in libthread or libpthread. POSIX/Austin/SUSv3 define these to be part of the real-time extensions also. Since our other real-time stuff (sched_*) is in libc, I'd say they really belong in libc. There is an option for semaphores too (_POSIX_SEMAPHORES); you probably want to define that if it isn't already (<sys/unistd.h> I think). Can they be implemented as standalone syscalls in libc, and then wrapped by libc_r? They needn't be wrapped at all in libpthread unless we want to make them faster for the non-shared case. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10209162113010.22806-100000>