On Oct 17, 2012, at 16:06, Nick Hutchinson <nshutchinson@gmail.com> wrote:
Hi Daniel,
Thanks for your repsonse. I've been poking around, and I think the dispatch_io test failures might point to a bug in libdispatch proper.
I don't understand most of the logic in io.c, but it seems that in certain cases, a Dispatch I/O channel's cleanup handler can execute concurrently with an I/O handler, instead of waiting until all I/O handler blocks have returned.
there is actually no guarantee that the channel cleanup handler must run after all I/O handlers have returned, just that it runs after all the I/O has completed and the file descriptor is safe to close (I/O handlers execute asynchronously to this).
I was experiencing this because there were a number of zero-length files in my /usr/lib folder, so the unit test was calling dispatch_io_read() with a `size` parameter of zero. Looking at the io.c code, I see that a request for a read or write of length zero is special-cased in _dispatch_operation_create(), and the I/O handler is enqueued immediately.
Maybe this is the source of the failures? If I update the dispatch_io.c test to call dispatch_io_read() with SIZE_MAX for the `size` parameter, the failures go away.
this may well be a bug in the test, I does not reproduce for me on Mac OS X when I add empty files to /usr/lib however. It would be interesting to investigate this further.
Regards, Nick
On 17/10/2012, at 8:03 PM, Daniel A. Steffen wrote:
Hi Nick,
awesome, thanks for the patches!
looking at the test failures:
the dispatch_vnode failure means not all vnode notifications were seen that should have been generated in response to the file rename()s perfomed, this is likely fixable by adjusting the dispatch_semaphore_wait timeout in the test, but could also indicate a problem in the kevent library or somewhere below
dispatch_starfish is essentially a stress test for multithreaded malloc, looks like the latency allowed by the test was exceeded in one case, this does not indicate a serious problem (the timing constants in the test would need to be adjusted for Linux for this to pass).
the dispatch_io failures look more serious and likely indicate a problem with the port of io.c, the asynchronous IO does not seem to be performed correctly, but I can't tell anything more specific about the cause from the output, so you'll probably need to do some debugging...
Daniel
On Oct 16, 2012, at 22:56, Nick Hutchinson <nshutchinson@gmail.com> wrote:
Hi all,
I've written some portability fixes to get Mountain Lion's libdispatch up and running on Linux, and my fork is up on Github for anyone who's interested: https://github.com/nickhutchinson/libdispatch.
I used Mark Heily's patches[1] that were previously posted on this list as a starting point. Note that I've had no previous experience with Autotools, and so the patches might be a little rough around the edges. Feedback is welcome.
The test suite builds, and most tests pass. However, the following three tests are failing, and I'd love to know why! - dispatch_starfish - dispatch_io - dispatch_vnode
The test output is here: https://gist.github.com/3903724
Cheers, Nick
[1] http://lists.macosforge.org/pipermail/libdispatch-dev/2012-August/000676.htm... _______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/libdispatch-dev