Charles-François Natali added the comment: > The reason I said above that those might be red-herring discoveries is this: > if I insert a short time.sleep(0.001) delay before the outer pipe-read loop, > the EINVAL errors don't get triggered either.
That's interesting. So it really seems that under certain conditions, a non-blocking read from an empty pipe could fail with EINVAL instead of EAGAIN. But this is definitely a bug, in such cases read() should return EAGAIN. > 1. Why doesn't the test encounter EINVAL in the range 127KB ... 1KB (when > iterating initialReadSize in *decreasing* order). If the pre-read delay is > significant, then does it take significantly more time to allocate a 127KB > chunk of memory than it does a 128KB chunk? > > 2. Why doesn't the test encounter EINVAL at all when iterating > initialReadSize in *increasing* order? I'm not sure it's a delay issue in this case. It may have more to do with the aligment of the buffer passed to read(). You can for example imagine that this error would show up only when the buffer is (or is not) aligned on a page boundary (usually 4K). As for the gap between 127KB and 128KB, it could be that we're allocating a new arena (we have a custom memory allocator over malloc()/mmap()), or that we switch between brk() and mmap(), but that's mere speculation, and there's nothing we can (and should) do here. I'm not sure about what to do with this, though: - adding a delay is out of question - retrying on EINVAL like on EAGAIN is not a good idead, since it could mask real bugs One thing we could do would be to limit the the call to read() to, let's say 64KB per call: """ newData = os.read(errpipe_read, min(65536, rSize)) """ But this would only work here, there are probably other places where this bug could be encountered (and I don't like adding hacks to avoid platform bugs). > I wrote a C-language program to reproduce this issue on Mac OS without Python. > I would like to file this issue with apple/Mac OS. What's the appropriate URL > for this? > I used g++ to compile test_fork_pipe_error.cpp on both Mac OS and on Linux. > EINVAL showed up only on Mac OS. Told you it was an OS-X bug (we've had several of those) ;-) As for where to report it, I'm making some OS-X enclined devs nosy. I'm suggest closing this bug as invalid (unless someone considers that we should try to work around it with the above trick). ---------- nosy: +hynek, ned.deily, ronaldoussoren _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15896> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
