[Python-Dev] test_pty.py hangs in verbose mode on Mac OS X?
Jean-Paul Calderone
exarkun at divmod.com
Fri Apr 13 17:07:04 CEST 2007
On Fri, 13 Apr 2007 11:02:01 -0400, Barry Warsaw <barry at python.org> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Apr 13, 2007, at 10:57 AM, Jean-Paul Calderone wrote:
>>>I don't know if this is caused by a bug in the Mac's pty
>>>implementation or something we're doing wrong on that platform. I
>>>played around with several modifications to pty.fork() on the Mac,
>>>including letting it drop down to the openpty()/os.fork() code, even
>>>adding an explicit ioctl(slave_fd, TIOCSCTTY) call which Stevens
>>>chapter 19 recommends for 4.3+BSD. I can't get it to not block.
>>
>>What about reading from the child in the parent before calling waitpid?
>
>Yep, this is what I suggested below. Porting the same change over to Linux
>produced an OSError, but that's probably just because I wasn't as careful
>as I should have been late last night.
>>>Barring a fix to pty.fork() (or possibly os.forkpty()) for the Mac,
>>>then I would like to at least make test_pty.py not block when run in
>>>verbose mode. A very simple hack would add something like this to
>>>the "if pid == pty.CHILD" stanza: "def debug(msg): pass", possibly
>>>protected by a "if verbose:". A less icky hack would be to read the
>>>output from the master_fd in the parent, though you have to be
>>>careful with that on Linux else the read can throw an input/output
>>>error.
>>>
>>>Disabling debug output is band-aid yes, and any application on the
>>>Mac like the above snippet will still fail. If anybody has any
>>>suggestions, I'm all ears, but I've reached the limit of my pty-fu.
>>
>>I don't think this is an OS X PTY bug. Writing to a blocking file
>>descriptor can block. Programs that do this need to account for the
>>possibility.
>
>Why doesn't it block on Linux then?
>
Likely differing buffering behavior. Prior to Linux 2.6, the pipe
implementation allowed only a single buffer (that is, the bytes from
a single write call) in a pipe at a time, and blocked subsequent
writes until that buffer was read. Recently this has changed to allow
multiple buffers up to 4k total length, so multiple short writes won't
block anymore. OS X may have some other buffering behavior which is
causing writes to block where they don't on Linux. All these details
are left to the platform, and there are a variety of behaviors which
can be considered valid.
Of course, I don't actually /know/ the cause of the problem here, but
this explanation seems plausible to me, and I'd investigate it before
looking for platform-specific pty bugs (although OS X is a good platform
on which to go looking for those ;).
Jean-Paul
More information about the Python-Dev
mailing list