[Python-Dev] test_pty.py hangs in verbose mode on Mac OS X? (original) (raw)

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(slavefd, 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 testpty.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 masterfd 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