libdispatch port to FreeBSD (was: [libdispatch-changes] [27] trunk/src)
Dear all-- I have committed an initial autoconf/automake/libtool build framework to libdispatch svn, and a first cut at conditionally compiling Apple-specific pieces of libdispatch. This allows libdispatch to build on both FreeBSD and Mac OS X Snow Leopard. Some notes for FreeBSD hackers: - Several kqueue extensions (EVFILT_USER, NOTE_TRIGGER, EV_RECEIPT, and EV_DISPATCH) are required in the FreeBSD kernel, and hopefully will go into the FreeBSD tree in the next couple of days. - Blocks are definitely not yet supported -- there seems to be a lot of interest, so I'm optimistic. As compilers aren't my forte, any assistance in this department would be most appreciated. :-) - On FreeBSD, there is no support for Apple's pthread work queue primitive, so I'm using the fallback worker code in libdispatch. The FreeBSD kernel community needs to have a conversation about the right way to address this requirement, but in the mean time the worker model should be fine. - There are also some kqueue events present in FreeBSD but not in Mac OS X; these may require tweaks to libdispatch to fully support by GCD-aware applications using these FreeBSD events. - I have developed and tested on a 32-bit Intel system; the comments below on -march on Mac OS X likely apply for FreeBSD/amd64 users as well. Some notes for Mac OS X hackers: - For now, you will need to hand-trim the -march line from src/Makefile. This should be fixed soon by some further autoconf work. - When I use the externally-built dylib on Snow Leopard, test programs spin. This may be due to interference between the libSystem dispatch code and the dylib -- possibly forcing the use of pthread_create_key rather than reserved keys would help. - I have not attempted to configure/build for Leopard as yet, but this change should make that a lot easier. EVFILT_USER is likely the biggest obstacle. Some notes for Linux hackers: - The lack of kqueue support is the critical obstacle in a port to Linux. It may be that a kqueue emulation library based on epoll (or even libevent) could fill this gap. If someone wants to look at this, pay very careful attention to kqueue semantics, as libdispatch relies on them heavily. Please consider this a work-in-progress -- don't be surprised when it doesn't build, let alone work. :-) Finally: this work would not have been possible without the support of Jordan Hubbard, Kevin Van Vechten, Dave Zarzycki, Bill Siegrist, and Apple. I am surprised by how easily the porting has gone so far -- it's a credit to their careful planning and quality of implementation that it has gone so smoothly. Thanks also to Peter O'Gorman and Colin Percival for their assistance with auto*, my nemesis. With any luck, there will be more good porting news to report in the near future! Thanks, Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Mon, 14 Sep 2009 11:46:19 -0700 (PDT) From: source_changes@macosforge.org Reply-To: libdispatch-dev@lists.macosforge.org To: libdispatch-changes@lists.macosforge.org Subject: [libdispatch-changes] [27] trunk/src Revision 27 Author robert@fledge.watson.org Date 2009-09-14 11:46:18 -0700 (Mon, 14 Sep 2009) Log Message Port of libdispatch to the FreeBSD operating system, which consisted of disabling various Mac OS X-specific portions of the library (such as Mach), providing portable versions of certain services internally (POSIX semaphores instead of Mach semaphores, clock_gettime() instead of mac_absolute_time()), and providing an autoconf/automake/libtool build infrastructure. This is just a first cut, refinement to follow. Conditionalize portions of the libdispatch build as follows: HAVE_MACH If Mach is present, support Mach ports throughout libdispatch. USE_LIBDISPATCH_INIT_CONSTRUCTOR If defined, add the 'constructor' attribute to libdispatch_init so that it runs as part of library initialization. This is not needed in Mac OS X libSystem due to explicit invocation of libpthread_init by libsyscall, but is for a stand-alone library. HAVE_DECL_EVFILT_SESSION, HAVE_DECL_NOTE_SIGNAL, HAVE_DECL_NOTE_REAP, HAVE_DECL_NOTE_NONE, HAVE_DECL_VQ_UPDATE, HAVE_DECL_VQ_VERYLOWDISK Conditionally support kqueue events that are not present on FreeBSD. DISPATCH_NO_LEGACY Expand the scope of this existing macro to allow libdispatch to build without legacy.c. HAVE_MACH_ABSOLUTE_TIME Wrap mach_absolute_time() in _dispatch_absolute_time(), and provide a portable clock_gettime() implementation. Some further refinment will be required here. USE_APPLE_SEMAPHORE_OPTIMIZATIONS Only use non-portable assembly optimizations of dispatch semaphores if supported. HAVE_SEM_INIT Use POSIX semaphores if Mach semaphores aren't present; further ifdef'ing possibly required here. If neither HAVE_MACH nor HAVE_SEM_INIT are present, the compile will fail. USE_APPLE_CRASHREPORTER_INFO Only define Mac OS X crashreporter state if requested. HAVE_PTHREAD_WORKQUEUES Only compile in support for pthread work queues if present; otherwise force use of normal worker threads. HAVE_PTHREAD_KEY_INIT_NP If defined, use non-portable allocation of pthread keys--otherwise, use pthread_create_key(). USE_APPLE_TSD_OPTIMIZATIONS Only use non-portable assembly optimizations if dispatch thread- specific data if this is defined. HAVE_MALLOC_CREATE_ZONE If not present, use compat/malloc_zone.h which implements the malloc zone APIs using normal malloc(3). Also fix some portability nits for building, such as casting before using long as a format string for several types. Note that this port will not build or run on a stock FreeBSD release or svn distribution yet, as it relies on kqueue extensions not committed back to FreeBSD yet. There are several known issues, such as how best to map CLOCK_UPTIME or CLOCK_MONOTONIC struct timespec timestamps into a Mach absolute time int64_t number space. Also, the POSIX semaphore ifdefing is adequate but not complete. Modified Paths * trunk/src/benchmark.c * trunk/src/dispatch.h * trunk/src/internal.h * trunk/src/legacy.h * trunk/src/os_shims.h * trunk/src/private.h * trunk/src/queue.c * trunk/src/queue_internal.h * trunk/src/semaphore.c * trunk/src/semaphore_internal.h * trunk/src/shims.c * trunk/src/source.c * trunk/src/source.h * trunk/src/source_private.h * trunk/src/time.c Diff Modified: trunk/src/benchmark.c (26 => 27)
Excellent! On Mon, Sep 14, 2009 at 1:05 PM, Robert Watson <robert@fledge.watson.org>wrote:
Dear all--
I have committed an initial autoconf/automake/libtool build framework to libdispatch svn, and a first cut at conditionally compiling Apple-specific pieces of libdispatch. This allows libdispatch to build on both FreeBSD and Mac OS X Snow Leopard.
Some notes for FreeBSD hackers:
- Several kqueue extensions (EVFILT_USER, NOTE_TRIGGER, EV_RECEIPT, and EV_DISPATCH) are required in the FreeBSD kernel, and hopefully will go into the FreeBSD tree in the next couple of days.
- Blocks are definitely not yet supported -- there seems to be a lot of interest, so I'm optimistic. As compilers aren't my forte, any assistance in this department would be most appreciated. :-)
- On FreeBSD, there is no support for Apple's pthread work queue primitive, so I'm using the fallback worker code in libdispatch. The FreeBSD kernel community needs to have a conversation about the right way to address this requirement, but in the mean time the worker model should be fine.
- There are also some kqueue events present in FreeBSD but not in Mac OS X; these may require tweaks to libdispatch to fully support by GCD-aware applications using these FreeBSD events.
- I have developed and tested on a 32-bit Intel system; the comments below on -march on Mac OS X likely apply for FreeBSD/amd64 users as well.
Some notes for Mac OS X hackers:
- For now, you will need to hand-trim the -march line from src/Makefile. This should be fixed soon by some further autoconf work.
- When I use the externally-built dylib on Snow Leopard, test programs spin. This may be due to interference between the libSystem dispatch code and the dylib -- possibly forcing the use of pthread_create_key rather than reserved keys would help.
- I have not attempted to configure/build for Leopard as yet, but this change should make that a lot easier. EVFILT_USER is likely the biggest obstacle.
Some notes for Linux hackers:
- The lack of kqueue support is the critical obstacle in a port to Linux. It may be that a kqueue emulation library based on epoll (or even libevent) could fill this gap. If someone wants to look at this, pay very careful attention to kqueue semantics, as libdispatch relies on them heavily.
Please consider this a work-in-progress -- don't be surprised when it doesn't build, let alone work. :-)
Finally: this work would not have been possible without the support of Jordan Hubbard, Kevin Van Vechten, Dave Zarzycki, Bill Siegrist, and Apple. I am surprised by how easily the porting has gone so far -- it's a credit to their careful planning and quality of implementation that it has gone so smoothly.
Thanks also to Peter O'Gorman and Colin Percival for their assistance with auto*, my nemesis.
With any luck, there will be more good porting news to report in the near future!
Thanks,
Robert N M Watson Computer Laboratory University of Cambridge
---------- Forwarded message ---------- Date: Mon, 14 Sep 2009 11:46:19 -0700 (PDT) From: source_changes@macosforge.org Reply-To: libdispatch-dev@lists.macosforge.org To: libdispatch-changes@lists.macosforge.org Subject: [libdispatch-changes] [27] trunk/src
Revision 27
Author robert@fledge.watson.org
Date 2009-09-14 11:46:18 -0700 (Mon, 14 Sep 2009)
Log Message
Port of libdispatch to the FreeBSD operating system, which consisted of disabling various Mac OS X-specific portions of the library (such as Mach), providing portable versions of certain services internally (POSIX semaphores instead of Mach semaphores, clock_gettime() instead of mac_absolute_time()), and providing an autoconf/automake/libtool build infrastructure. This is just a first cut, refinement to follow.
Conditionalize portions of the libdispatch build as follows:
HAVE_MACH If Mach is present, support Mach ports throughout libdispatch.
USE_LIBDISPATCH_INIT_CONSTRUCTOR If defined, add the 'constructor' attribute to libdispatch_init so that it runs as part of library initialization. This is not needed in Mac OS X libSystem due to explicit invocation of libpthread_init by libsyscall, but is for a stand-alone library.
HAVE_DECL_EVFILT_SESSION, HAVE_DECL_NOTE_SIGNAL, HAVE_DECL_NOTE_REAP, HAVE_DECL_NOTE_NONE, HAVE_DECL_VQ_UPDATE, HAVE_DECL_VQ_VERYLOWDISK Conditionally support kqueue events that are not present on FreeBSD.
DISPATCH_NO_LEGACY Expand the scope of this existing macro to allow libdispatch to build without legacy.c.
HAVE_MACH_ABSOLUTE_TIME Wrap mach_absolute_time() in _dispatch_absolute_time(), and provide a portable clock_gettime() implementation. Some further refinment will be required here.
USE_APPLE_SEMAPHORE_OPTIMIZATIONS Only use non-portable assembly optimizations of dispatch semaphores if supported.
HAVE_SEM_INIT Use POSIX semaphores if Mach semaphores aren't present; further ifdef'ing possibly required here. If neither HAVE_MACH nor HAVE_SEM_INIT are present, the compile will fail.
USE_APPLE_CRASHREPORTER_INFO Only define Mac OS X crashreporter state if requested.
HAVE_PTHREAD_WORKQUEUES Only compile in support for pthread work queues if present; otherwise force use of normal worker threads.
HAVE_PTHREAD_KEY_INIT_NP If defined, use non-portable allocation of pthread keys--otherwise, use pthread_create_key().
USE_APPLE_TSD_OPTIMIZATIONS Only use non-portable assembly optimizations if dispatch thread- specific data if this is defined.
HAVE_MALLOC_CREATE_ZONE If not present, use compat/malloc_zone.h which implements the malloc zone APIs using normal malloc(3).
Also fix some portability nits for building, such as casting before using long as a format string for several types. Note that this port will not build or run on a stock FreeBSD release or svn distribution yet, as it relies on kqueue extensions not committed back to FreeBSD yet.
There are several known issues, such as how best to map CLOCK_UPTIME or CLOCK_MONOTONIC struct timespec timestamps into a Mach absolute time int64_t number space. Also, the POSIX semaphore ifdefing is adequate but not complete.
Modified Paths
* trunk/src/benchmark.c * trunk/src/dispatch.h * trunk/src/internal.h * trunk/src/legacy.h * trunk/src/os_shims.h * trunk/src/private.h * trunk/src/queue.c * trunk/src/queue_internal.h * trunk/src/semaphore.c * trunk/src/semaphore_internal.h * trunk/src/shims.c * trunk/src/source.c * trunk/src/source.h * trunk/src/source_private.h * trunk/src/time.c
Diff
Modified: trunk/src/benchmark.c (26 => 27) _______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev
Hi Robert, On Mon, Sep 14, 2009 at 4:05 PM, Robert Watson <robert@fledge.watson.org> wrote:
Dear all--
I have committed an initial autoconf/automake/libtool build framework to libdispatch svn, and a first cut at conditionally compiling Apple-specific pieces of libdispatch. This allows libdispatch to build on both FreeBSD and Mac OS X Snow Leopard.
Thats great, from the looks of it it must have taken a lot of time to split it up so much!
Some notes for FreeBSD hackers:
- Several kqueue extensions (EVFILT_USER, NOTE_TRIGGER, EV_RECEIPT, and EV_DISPATCH) are required in the FreeBSD kernel, and hopefully will go into the FreeBSD tree in the next couple of days.
- Blocks are definitely not yet supported -- there seems to be a lot of interest, so I'm optimistic. As compilers aren't my forte, any assistance in this department would be most appreciated. :-)
- On FreeBSD, there is no support for Apple's pthread work queue primitive, so I'm using the fallback worker code in libdispatch. The FreeBSD kernel community needs to have a conversation about the right way to address this requirement, but in the mean time the worker model should be fine.
- There are also some kqueue events present in FreeBSD but not in Mac OS X; these may require tweaks to libdispatch to fully support by GCD-aware applications using these FreeBSD events.
- I have developed and tested on a 32-bit Intel system; the comments below on -march on Mac OS X likely apply for FreeBSD/amd64 users as well.
Some notes for Mac OS X hackers:
- For now, you will need to hand-trim the -march line from src/Makefile. This should be fixed soon by some further autoconf work.
- When I use the externally-built dylib on Snow Leopard, test programs spin. This may be due to interference between the libSystem dispatch code and the dylib -- possibly forcing the use of pthread_create_key rather than reserved keys would help.
- I have not attempted to configure/build for Leopard as yet, but this change should make that a lot easier. EVFILT_USER is likely the biggest obstacle.
Some notes for Linux hackers:
- The lack of kqueue support is the critical obstacle in a port to Linux. It may be that a kqueue emulation library based on epoll (or even libevent) could fill this gap. If someone wants to look at this, pay very careful attention to kqueue semantics, as libdispatch relies on them heavily.
I am quite interested in this, but don't have much experience yet with event interfaces. I'll try to prepare some thoughts by the end of the week, but libevent seems very interesting. Thanks for all the work so far. yours, Bobby
Please consider this a work-in-progress -- don't be surprised when it doesn't build, let alone work. :-)
Finally: this work would not have been possible without the support of Jordan Hubbard, Kevin Van Vechten, Dave Zarzycki, Bill Siegrist, and Apple. I am surprised by how easily the porting has gone so far -- it's a credit to their careful planning and quality of implementation that it has gone so smoothly.
Thanks also to Peter O'Gorman and Colin Percival for their assistance with auto*, my nemesis.
With any luck, there will be more good porting news to report in the near future!
Thanks,
Robert N M Watson Computer Laboratory University of Cambridge
---------- Forwarded message ---------- Date: Mon, 14 Sep 2009 11:46:19 -0700 (PDT) From: source_changes@macosforge.org Reply-To: libdispatch-dev@lists.macosforge.org To: libdispatch-changes@lists.macosforge.org Subject: [libdispatch-changes] [27] trunk/src
Revision 27
Author robert@fledge.watson.org
Date 2009-09-14 11:46:18 -0700 (Mon, 14 Sep 2009)
Log Message
Port of libdispatch to the FreeBSD operating system, which consisted of disabling various Mac OS X-specific portions of the library (such as Mach), providing portable versions of certain services internally (POSIX semaphores instead of Mach semaphores, clock_gettime() instead of mac_absolute_time()), and providing an autoconf/automake/libtool build infrastructure. This is just a first cut, refinement to follow.
Conditionalize portions of the libdispatch build as follows:
HAVE_MACH If Mach is present, support Mach ports throughout libdispatch.
USE_LIBDISPATCH_INIT_CONSTRUCTOR If defined, add the 'constructor' attribute to libdispatch_init so that it runs as part of library initialization. This is not needed in Mac OS X libSystem due to explicit invocation of libpthread_init by libsyscall, but is for a stand-alone library.
HAVE_DECL_EVFILT_SESSION, HAVE_DECL_NOTE_SIGNAL, HAVE_DECL_NOTE_REAP, HAVE_DECL_NOTE_NONE, HAVE_DECL_VQ_UPDATE, HAVE_DECL_VQ_VERYLOWDISK Conditionally support kqueue events that are not present on FreeBSD.
DISPATCH_NO_LEGACY Expand the scope of this existing macro to allow libdispatch to build without legacy.c.
HAVE_MACH_ABSOLUTE_TIME Wrap mach_absolute_time() in _dispatch_absolute_time(), and provide a portable clock_gettime() implementation. Some further refinment will be required here.
USE_APPLE_SEMAPHORE_OPTIMIZATIONS Only use non-portable assembly optimizations of dispatch semaphores if supported.
HAVE_SEM_INIT Use POSIX semaphores if Mach semaphores aren't present; further ifdef'ing possibly required here. If neither HAVE_MACH nor HAVE_SEM_INIT are present, the compile will fail.
USE_APPLE_CRASHREPORTER_INFO Only define Mac OS X crashreporter state if requested.
HAVE_PTHREAD_WORKQUEUES Only compile in support for pthread work queues if present; otherwise force use of normal worker threads.
HAVE_PTHREAD_KEY_INIT_NP If defined, use non-portable allocation of pthread keys--otherwise, use pthread_create_key().
USE_APPLE_TSD_OPTIMIZATIONS Only use non-portable assembly optimizations if dispatch thread- specific data if this is defined.
HAVE_MALLOC_CREATE_ZONE If not present, use compat/malloc_zone.h which implements the malloc zone APIs using normal malloc(3).
Also fix some portability nits for building, such as casting before using long as a format string for several types. Note that this port will not build or run on a stock FreeBSD release or svn distribution yet, as it relies on kqueue extensions not committed back to FreeBSD yet.
There are several known issues, such as how best to map CLOCK_UPTIME or CLOCK_MONOTONIC struct timespec timestamps into a Mach absolute time int64_t number space. Also, the POSIX semaphore ifdefing is adequate but not complete.
Modified Paths
* trunk/src/benchmark.c * trunk/src/dispatch.h * trunk/src/internal.h * trunk/src/legacy.h * trunk/src/os_shims.h * trunk/src/private.h * trunk/src/queue.c * trunk/src/queue_internal.h * trunk/src/semaphore.c * trunk/src/semaphore_internal.h * trunk/src/shims.c * trunk/src/source.c * trunk/src/source.h * trunk/src/source_private.h * trunk/src/time.c
Diff
Modified: trunk/src/benchmark.c (26 => 27) _______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev
On Sep 14, 2009, at 1:05 PM, Robert Watson wrote:
I have committed an initial autoconf/automake/libtool build framework to libdispatch svn, and a first cut at conditionally compiling Apple-specific pieces of libdispatch. This allows libdispatch to build on both FreeBSD and Mac OS X Snow Leopard.
Awesome news, thanks Robert! Since I'm sure the question is on everyone's minds, could you say a thing or two about the functionality of the "port" at this stage? Does this simply compile but not run, or is there a limited subset of APIs which are already callable? Regarding the compiler and blocks support, one assumes that the existing clang work in FreeBSD can be directly leveraged since clang has supported blocks since earlier this summer and GCD is happy to build with clang. There's also Apple's GCC branch (svn://gcc.gnu.org/svn/gcc/branches/apple-200511-release-branch is the right one, I *think*, though there's also the definitive source drop for SnowLeopard which we publish at http://www.opensource.apple.com/source/gcc/gcc-5646 , so it's probably not even necessary to look through the FSF's branches. I'm not sure how much work our code drop will require to build on FreeBSD - it doesn't quite build out of the box (I tried) but I suspect the block support changes could just as easily be pulled out and retrofitted to FreeBSD's default compiler in any case. We build things differently at Apple, and I suspect the problems I'm having building our branch reflect that, so simply pulling the relevant changes out would sort of cut the Gordion knot here. Then again, there's clang, which represents the path forward for all the *BSDs, at least. GCC+Blocks is more of a Linux requirement. - Jordan
University of Cambridge On Mon, 14 Sep 2009, Jordan K. Hubbard wrote:
On Sep 14, 2009, at 1:05 PM, Robert Watson wrote:
I have committed an initial autoconf/automake/libtool build framework to libdispatch svn, and a first cut at conditionally compiling Apple-specific pieces of libdispatch. This allows libdispatch to build on both FreeBSD and Mac OS X Snow Leopard.
Awesome news, thanks Robert!
Since I'm sure the question is on everyone's minds, could you say a thing or two about the functionality of the "port" at this stage? Does this simply compile but not run, or is there a limited subset of APIs which are already callable?
Hi Jordan-- The quick answer is: yes, libdispatch now runs on FreeBSD. The qualified answer: Stacey and I are currently working to review/test the kernel kqueue changes required to make the libdispatch svn code run properly on FreeBSD. We hope to get at least the first kernel patch, if not all of them, into FreeBSD 9-CURRENT tonight. This is all without blocks, and without pthread workqueues. I've also learned from Kevin that the FreeBSD porting work appears not to have broken libdispatch on Snow Leopard, which is pleasing news too :-). Robert N M Watson Computer Laboratory University of Cambridge
On Mon, 2009-09-14 at 21:05 +0100, Robert Watson wrote:
Dear all--
Some notes for Linux hackers:
- The lack of kqueue support is the critical obstacle in a port to Linux. It may be that a kqueue emulation library based on epoll (or even libevent) could fill this gap. If someone wants to look at this, pay very careful attention to kqueue semantics, as libdispatch relies on them heavily.
That was also my thought after some initial poking in the code. I did stuble on a Linux API (Net:Kevent) today but haven't looked into it yet. I am not a hardcore linux coder, but would like to get involved in this. Great work, Robert and Co. cheers, :-Dennis
On 14 Sep 2009, at 22:38, Dennis Schafroth wrote:
On Mon, 2009-09-14 at 21:05 +0100, Robert Watson wrote:
- The lack of kqueue support is the critical obstacle in a port to Linux. It may be that a kqueue emulation library based on epoll (or even libevent) could fill this gap. If someone wants to look at this, pay very careful attention to kqueue semantics, as libdispatch relies on them heavily.
That was also my thought after some initial poking in the code. I did stuble on a Linux API (Net:Kevent) today but haven't looked into it yet.
I am not a hardcore linux coder, but would like to get involved in this.
Just waving my hands at this point, but: if it were possible to accomplish a lot of this with libevent or an enhanced version of libevent, it would give us greater portability to other OS's, including Opensolaris. Robert
On Sep 14, 2009, at 3:05 PM, Robert Watson wrote:
Some notes for FreeBSD hackers:
- Several kqueue extensions (EVFILT_USER, NOTE_TRIGGER, EV_RECEIPT, and EV_DISPATCH) are required in the FreeBSD kernel, and hopefully will go into the FreeBSD tree in the next couple of days.
Hi Robert: Thanks for creating the initial port. I have some patches for the FreeBSD kevent code to add "touch" filter hooks, EVFILT_USER, NOTE_TRIGGER, and EV_DISPATCH that I'll send your way to review. I have looked at EV_RECEIPT briefly and I am not sure how useful or necessary it is for this port. Maybe someone could comment on that. Thanks in advance, -stacey. sson@FreeBSD.org
On Sep 14, 2009, at 3:20 PM, Stacey Son wrote:
I have some patches for the FreeBSD kevent code to add "touch" filter hooks, EVFILT_USER, NOTE_TRIGGER, and EV_DISPATCH that I'll send your way to review. I have looked at EV_RECEIPT briefly and I am not sure how useful or necessary it is for this port. Maybe someone could comment on that.
EV_RECEIPT is useful to disambiguating error conditions when multiple structures are passed to kevent(2); or to disambiguate error conditions in kevent(2) itself and the action requested (for example EBADF may refer to either the kqueue file descriptor or the file descriptor to monitor). Kevin
On Sep 14, 2009, at 7:19 PM, Kevin Van Vechten wrote:
EV_RECEIPT is useful to disambiguating error conditions when multiple structures are passed to kevent(2); or to disambiguate error conditions in kevent(2) itself and the action requested (for example EBADF may refer to either the kqueue file descriptor or the file descriptor to monitor).
Kevin, Thanks for the clarification. I have created another patch for FreeBSD to add EV_RECEIPT. Robert, Look for another patch coming your way to review. Best Regards, -stacey.
participants (8)
-
Bobby Powers
-
David Leimbach
-
Dennis Schafroth
-
Jordan K. Hubbard
-
Kevin Van Vechten
-
Robert N. M. Watson
-
Robert Watson
-
Stacey Son