Date: Tue, 12 Mar 2002 23:32:25 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Craig Rodrigues <crodrigu@bbn.com> Cc: freebsd-hackers@freebsd.org Subject: Re: How to correctly detect POSIX 1003.1b features on FreeBSD? Message-ID: <3C8F0089.40C63E1D@mindspring.com> References: <20020312140904.A799@bbn.com> <3C8E742C.7C2E63B8@mindspring.com> <20020312193514.A2226@bbn.com> <20020313005940.GB32410@elvis.mu.org> <20020312201314.A2345@bbn.com> <3C8EB31E.19382903@mindspring.com> <20020312214007.A2526@bbn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Craig Rodrigues wrote: > On Tue, Mar 12, 2002 at 06:02:06PM -0800, Terry Lambert wrote: > > I told you twice already: > > I got the e-mail from Albert Perlstein telling me to check > __FreeBSD_Version before I got your e-mail telling me to > check for _POSIX_REALTIME_SIGNALS. > > Sorry for the cross-traffic. No problem; it just gets frustrating. 8-). > > Isn't this covered in the reference where you are finding the > > definition of these functions so that you are able to even know > > how to call them correctly in the first place? > > No it is not covered. My reference has been the posix4(9) man page, > and <signal.h> which is available on FreeBSD 4.3. The POSIX specification itself is a better reference for POSIX. The copy I have is old, and the Single Unix Specifications I have (the Go Solo 2, and the earlier Draft of the Spec. 1770 from the UNIX International FTP site before it dies in the mid 1990's) aren't exactly the same thing as POSIX (they are X/Open documents, not IEEE). Unfortunately, the real thing is expensive, but necessary, if you are going to use the features it defines in as portable a way as possible. > I am a contributor to ACE, a cross-platform C++ library > for doing systems programming: http://www.cs.wustl.edu/~schmidt/ACE.html. I know ACE; I like it, actually. 8-). > My intent is to fix the macros in ACE which define the > configuration on FreeBSD (all FreeBSD specific configuration data > is in ACE's config-freebsd-pthread.h). Right now the ACE macros which detect > AIO and RT signals are broken, so I am trying to fix these macros, > hence my questions on this mailing list. I'm not looking to specifically > use POSIX RT signals on FreeBSD, I just want to get ACE to cleanly > compile on FreeBSD, so that FreeBSD users can use and enjoy ACE > on their projects if they choose. The RT stuff is the one listed; the AIO stuff, I'd have to look up; have you found it yet? Or do I need to go diving? > > The POSIX > > standard clearly covers all the feature test macros for the > > optional implementation parts of the standard, which includes > > the RT extensions. > > I wasn't referring to the POSIX standard, I was referring to > the <signal.h> and posix4(9) man page which came with FreeBSD. > I'll refer to the POSIX standard from now on. Yeah, it'd make it a lot clearer. Sorry for being short. The actual standard is always best; in the worst case, you can use it to brow-beat the FreeBSD folks into supporting the correct feature-test macros mandated by the standard, and/or add them to FreeBSD to bring it into compliance. I had the same battle (actually, Jeremy Allison and I had the battle with FreeBSD 3.x) when we brought the threads into tighter compliance with the threads Draft 4 standard. It then went off into the weeds by defining the manifests used for the feature testing in the STL and other programs (ACAP, UMICH LDAP, etc.) for which we needed the Draft 4 compliance, without actually complying. It's much, much better to comply with an old standard, than to be partway between one standard and another. > > When (if) the feature is ever actuallysupported by FreeBSD, > > the manifest constant _POSIX_REALTIME_SIGNALS will be > > defined. > > Ahh! OK, this is the information that I am most interested in. > So, I am now confident to re-write the test in ACE to: > > #ifdef _POSIX_REALTIME_SIGNALS > > /* use sigqueue(), etc. */ > > #endif > > This test will work for ACE users on older and newer versions of FreeBSD, > and when POSIX RT signals are fully implemented on FreeBSD, ACE will use > them. Yes. > Thanks for your help! Not really my doing; I'm not committing to this; I'm just positive that the POSIX mavens in the FreeBSD camp will make sure that the feature test macros do what the standard says they do, even if they have to be hit over the head with a ton of $8 per page official documentation. 8-). > > If you want to support it by writing the code for FreeBSD > > support yourself, the Linux code is available from: > > > > http://hegel.ittc.ukans.edu/projects/posix/signals.html > > I do not intend to implement POSIX realtime signals for FreeBSD > at this time. I don't think anyone does, actually... with kqueue, the POSIX RT stuff for queued signal delivery is much less general, and so a lot less useful than the queued signal velivery FreeBSD already supports, merely by registering for the signal kevents, which will be queued and delivered reliably. The entire idea of "reliable signals" sort of discredits the whole premise of "signals are persistant conditions, not events" model. It's a broken idea that's based on programmers being unable to use signals correctly. I'm really surprised that ACE has any use for RT signals at all. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C8F0089.40C63E1D>