[libdispatch-dev] Mountain Lion libdispatch for Linux

[Daniel A. Steffen]

On Oct 17, 2012, at 16:06, Nick Hutchinson <nshutchinson at 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 at 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.html
>>> _______________________________________________
>>> libdispatch-dev mailing list
>>> libdispatch-dev at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo/libdispatch-dev
>> 
>