[Python-Dev] Re: PEP 324 (process module) (original) (raw)

Trent Mick trentm at ActiveState.com
Wed Aug 4 20:30:56 CEST 2004

[Peter Astrand wrote]

> ProcessProxy: > ...a behemoth using a thread for each of stdin/stdout/stderr to > allow the user to get an event-like IO interface.

Why not avoid threads on POSIX systems, and use select instead? My module does, although it does not provide an event-like IO interface.

Because that wouldn't be cross-platform... perhaps it would be possible though. I am not that experienced with select() -- I have generally eschewed it because I can't use it on Windows as well.

If you get rid of the threads, then you don't need the workaround code for Linux.

Slight misunderstanding there: the separate thread from which you cannot kill a subprocess on Linux is not one of these ProcessProxy threads. I.e. ignoring ProcessProxy the LinuxThreads-bug workaround is still necessary for Process and ProcessOpen for the user that starts a subprocess on their thread-A and wants to kill it on their thread-B.

You're right. My module should probably have an option for invoking through the shell, or at least document how to do it. I really don't want it as default, though.

I have code to find the shell adequately so I don't see why we couldn't use it. As to making it the default or not: perhaps clear documentation could help avoid the expected "I can't run 'dir'!" newbie complaint, but I don't think it would get all of the them. The current popen*() execute via the shell. The lower-level guys, exec*() and spawn*(), do not. Still up for debate, I guess. :)

> - My module includes some handling that for subsystem:windows vs. > subsystem:console apps on Windows that I don't think yours does.

Can you describe why this is needed/useful?

A subsystem:windows app (like Komodo, or Idle, or pythonw.exe, or any GUI app) doesn't have a console and hence doesn't have std handles. By default, executing any subsytem:console app (like 'ls' or 'echo' or 'python' or 'perl) from a subsystem:windows app will result in an AllocConsole call (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/allocconsole.asp) that will result in a console dialog popping up. You can see this on some Windows apps that haven't dealt with this issue. In particular, some installers out there will pop up an unprofessional console dialog when running some sub-processes. To avoid this one has to muck around with CreateProcess options. Or, kind of the reverse, if a seeming GUI app does have std handles (often redirected to log files, Komodo does this) and it wants to offer the ability to pop up a console (e.g. Komodo's feature to debug in a separate console) then one needs the ability to specify CREATE_NEW_CONSOLE.

I can change, but I'd like more feedback before that. No-one has told me their opinion on the name "subprocess", for example, not even you :-)

Sure, I don't mind "subprocess". I am hoping, though, that we can eventually merge our two modules and just call that one "process".

Trent

-- Trent Mick TrentM at ActiveState.com

More information about the Python-Dev mailing list