Date: Mon, 16 Sep 2002 21:49:14 -0400 (EDT) From: Garrett Wollman <wollman@lcs.mit.edu> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: standards@FreeBSD.ORG Subject: Re: sem_* API Message-ID: <200209170149.g8H1nEOS026795@khavrinen.lcs.mit.edu> In-Reply-To: <Pine.GSO.4.10.10209162113010.22806-100000@pcnet1.pcnet.com> References: <20020917010939.GE86737@elvis.mu.org> <Pine.GSO.4.10.10209162113010.22806-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Mon, 16 Sep 2002 21:32:03 -0400 (EDT), Daniel Eischen <eischen@pcnet1.pcnet.com> said: > 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. Semaphores must be available in a `c99 -l rt' compilation environment, whether or not `-l pthread' is also specified, if the semaphore option is supported. Note that the specification of `c99' explicitly states that there need not be an explicit `librt.a' or `libpthread.a'; the compiler driver must make the relevant routines available when those arguments are specified (and may make them available at any other time). > 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). If this feature is going to be optional in the kernel, it should not be defined, and programs should instead use the appropriate sysconf() test to determine whether it works or not. > 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. Agreed. -GAWollman 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?200209170149.g8H1nEOS026795>