[Twisted-Python] spawnProcess under Win32
Hi! I had recently to use the Process protocol of Twisted (win32eventreactor) to launch some applications and grab their output. It works well, the only problem I have is Twisted always opens a DOS console. Since I receive the output and treat them myself, the DOS console stays empty. But in fact, I would never want this console to appear on screen. I've looked at the way Twisted creates a process under Win32 and I've noticed that it uses the CreateProcess() function. The problem is it doesn't mention any creation flags (i.e.: it just passes 0) whereas here, we would need to pass DETACHED_PROCESS to avoid a new console to be created. What I've done is merely to add an optional win32flags argument to the spawnProcess() method in win32eventreactor.py as follow: http://cvs.gna.org/cvsweb/envwin32/python/Lib/site-packages/twisted/internet... I would be interested to know what do you think about this? Does it seem to you a good idea? Sincerely, Igor.
On Mon, 14 Aug 2006 15:15:55 +0200, Igor Kravtchenko
Hi!
I've looked at the way Twisted creates a process under Win32 and I've noticed that it uses the CreateProcess() function. The problem is it doesn't mention any creation flags (i.e.: it just passes 0) whereas here, we would need to pass DETACHED_PROCESS to avoid a new console to be created.
I would be interested to know what do you think about this? Does it seem to you a good idea?
Well, we do have a UNIX-specific argument to spawnProcess (usePTY), so I don't see why we couldn't have a Win32-specific argument as well. However, "win32flags" seems like a pretty vague name, especially since it could be CreateProcess's dwCreationFlags argument or STARTUPINFO's dwFlags attribute. Also, depending on context, you might want CREATE_NO_WINDOW or DETACHED_PROCESS or possibly both. I believe the right thing to do is to come up with some typical features of the Windows process environment and support them explicitly. I don't believe all the flags you can pass to CreateProcess are compatible with the way Twisted expects subprocesses to behave, and I am definitely sure that not all the things you can put in STARTUPINFO are.
Hi, yes I see your point of view. I deliberately passed that Win32 flags since I didn't wanted to get in details of what kind of Win32 features we need or not. It can indeed potentially breaks Twisted behavior if incorrect flags are passed. However it's just easier even if less secure. Otherwise, you have to enumerate all kind of features users want and implement them explicitly while having the correct code guard to prevent from crash or incorrect behavior. I don't know about other Win32 developpers. From my side, I just wanted a way to prevent a console to be opened, so might be something like an explicit CREATE_NO_CONSOLE flag or such. Igor. glyph@divmod.com wrote:
On Mon, 14 Aug 2006 15:15:55 +0200, Igor Kravtchenko
wrote: Hi!
I've looked at the way Twisted creates a process under Win32 and I've noticed that it uses the CreateProcess() function. The problem is it doesn't mention any creation flags (i.e.: it just passes 0) whereas here, we would need to pass DETACHED_PROCESS to avoid a new console to be created.
I would be interested to know what do you think about this? Does it seem to you a good idea?
Well, we do have a UNIX-specific argument to spawnProcess (usePTY), so I don't see why we couldn't have a Win32-specific argument as well. However, "win32flags" seems like a pretty vague name, especially since it could be CreateProcess's dwCreationFlags argument or STARTUPINFO's dwFlags attribute.
Also, depending on context, you might want CREATE_NO_WINDOW or DETACHED_PROCESS or possibly both.
I believe the right thing to do is to come up with some typical features of the Windows process environment and support them explicitly. I don't believe all the flags you can pass to CreateProcess are compatible with the way Twisted expects subprocesses to behave, and I am definitely sure that not all the things you can put in STARTUPINFO are.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Mon, 14 Aug 2006 17:02:07 +0200, Igor Kravtchenko
glyph@divmod.com wrote:
On Mon, 14 Aug 2006 15:15:55 +0200, Igor Kravtchenko
wrote: Hi!
I've looked at the way Twisted creates a process under Win32 and I've noticed that it uses the CreateProcess() function. The problem is it doesn't mention any creation flags (i.e.: it just passes 0) whereas here, we would need to pass DETACHED_PROCESS to avoid a new console to be created.
I would be interested to know what do you think about this? Does it seem to you a good idea?
Well, we do have a UNIX-specific argument to spawnProcess (usePTY), so I don't see why we couldn't have a Win32-specific argument as well. However, "win32flags" seems like a pretty vague name, especially since it could be CreateProcess's dwCreationFlags argument or STARTUPINFO's dwFlags attribute.
Also, depending on context, you might want CREATE_NO_WINDOW or DETACHED_PROCESS or possibly both.
I believe the right thing to do is to come up with some typical features of the Windows process environment and support them explicitly. I don't believe all the flags you can pass to CreateProcess are compatible with the way Twisted expects subprocesses to behave, and I am definitely sure that not all the things you can put in STARTUPINFO are.
Hi,
yes I see your point of view. I deliberately passed that Win32 flags since I didn't wanted to get in details of what kind of Win32 features we need or not. It can indeed potentially breaks Twisted behavior if incorrect flags are passed.
However it's just easier even if less secure. Otherwise, you have to enumerate all kind of features users want and implement them explicitly while having the correct code guard to prevent from crash or incorrect behavior.
I don't know about other Win32 developpers. From my side, I just wanted a way to prevent a console to be opened, so might be something like an explicit CREATE_NO_CONSOLE flag or such.
It's easier on the Twisted side. It's harder on application developers, since they have to know if they want to pass CREATE_NO_CONSOLE or CREATE_NO_WINDOW or DETACHED_PROCESS or some combination or some other flag entirely. It also makes it completely non-portable to other platforms. It's difficult to do anything with subprocesses cross-platform, but the goal should be to make it possible and then easy. Requiring Win32 flags to be passed in is complete capitulation. I also wonder why I have never noticed this behavior. For example, I have run buildslaves on Win32 and never noticed them popping up console windows. Does this behavior differ between different version of Windows? Also, please don't top-post. Jean-Paul
Jean-Paul Calderone wrote:
On Mon, 14 Aug 2006 17:02:07 +0200, Igor Kravtchenko
wrote: glyph@divmod.com wrote:
On Mon, 14 Aug 2006 15:15:55 +0200, Igor Kravtchenko
wrote: Hi!
I've looked at the way Twisted creates a process under Win32 and I've noticed that it uses the CreateProcess() function. The problem is it doesn't mention any creation flags (i.e.: it just passes 0) whereas here, we would need to pass DETACHED_PROCESS to avoid a new console to be created.
I would be interested to know what do you think about this? Does it seem to you a good idea?
Well, we do have a UNIX-specific argument to spawnProcess (usePTY), so I don't see why we couldn't have a Win32-specific argument as well. However, "win32flags" seems like a pretty vague name, especially since it could be CreateProcess's dwCreationFlags argument or STARTUPINFO's dwFlags attribute.
Also, depending on context, you might want CREATE_NO_WINDOW or DETACHED_PROCESS or possibly both.
I believe the right thing to do is to come up with some typical features of the Windows process environment and support them explicitly. I don't believe all the flags you can pass to CreateProcess are compatible with the way Twisted expects subprocesses to behave, and I am definitely sure that not all the things you can put in STARTUPINFO are.
Hi,
yes I see your point of view. I deliberately passed that Win32 flags since I didn't wanted to get in details of what kind of Win32 features we need or not. It can indeed potentially breaks Twisted behavior if incorrect flags are passed.
However it's just easier even if less secure. Otherwise, you have to enumerate all kind of features users want and implement them explicitly while having the correct code guard to prevent from crash or incorrect behavior.
I don't know about other Win32 developpers. From my side, I just wanted a way to prevent a console to be opened, so might be something like an explicit CREATE_NO_CONSOLE flag or such.
It's easier on the Twisted side. It's harder on application developers, since they have to know if they want to pass CREATE_NO_CONSOLE or CREATE_NO_WINDOW or DETACHED_PROCESS or some combination or some other flag entirely.
It also makes it completely non-portable to other platforms. It's difficult to do anything with subprocesses cross-platform, but the goal should be to make it possible and then easy. Requiring Win32 flags to be passed in is complete capitulation.
I also wonder why I have never noticed this behavior. For example, I have run buildslaves on Win32 and never noticed them popping up console windows. Does this behavior differ between different version of Windows?
I don't thing. What I have is a Windows SubSystem .exe (WinMain() entry point) launching a bunch of Consoles Subsystem .exe (main() entry point). Since the applications are console based, it's not surprising to see them. DETACHED_PROCESS does the trick and console applications have to call AllocConsole() explicitly to open a console. Igor.
It also makes it completely non-portable to other platforms. It's difficult to do anything with subprocesses cross-platform, but the goal should be to make it possible and then easy. Requiring Win32 flags to be passed in is complete capitulation.
Actually it's not that difficult, if you have programs that simply read stdin and write to stdout. I'm running a some backup tool (dar) with commands/events and responses communicated via stdin/stderr both on Unix and Windows with exactly the same twisted code and its working nicely.
I also wonder why I have never noticed this behavior. For example, I have run buildslaves on Win32 and never noticed them popping up console windows. Does this behavior differ between different version of Windows?
I also don't seem to have any problems with unwanted console processes but that maybe because the current spawnProcess implementation seems to copy the process creation flags from the main process, and I'm only running that program from the console (where there is no need to create another one) or as a Windows service (which doesn't have a console). Maybe the original poster is running processes that open a new console themselves explicitly?
I've recently fixed a problem in MPI 1.2.1 launching program RemoteShell. It uses CreateProcessAsUser to spawn a process. The RemoteShell runs as a service(daemon) and spawn a new process perfectly (without DOS window). The followings are C-code, it might give you some hint. if (CreateProcess( NULL, tCmdLine, NULL, NULL, TRUE, //DETACHED_PROCESS | IDLE_PRIORITY_CLASS, //CREATE_NO_WINDOW | IDLE_PRIORITY_CLASS, CREATE_NO_WINDOW | IDLE_PRIORITY_CLASS | CREATE_NEW_PROCESS_GROUP, //DETACHED_PROCESS | IDLE_PRIORITY_CLASS | CREATE_NEW_PROCESS_GROUP, //CREATE_NO_WINDOW | IDLE_PRIORITY_CLASS | CREATE_SUSPENDED, pEnv, NULL, &saInfo, &psInfo)) Igor Kravtchenko wrote:
Hi,
yes I see your point of view. I deliberately passed that Win32 flags since I didn't wanted to get in details of what kind of Win32 features we need or not. It can indeed potentially breaks Twisted behavior if incorrect flags are passed.
However it's just easier even if less secure. Otherwise, you have to enumerate all kind of features users want and implement them explicitly while having the correct code guard to prevent from crash or incorrect behavior.
I don't know about other Win32 developpers. From my side, I just wanted a way to prevent a console to be opened, so might be something like an explicit CREATE_NO_CONSOLE flag or such.
Igor.
glyph@divmod.com wrote:
On Mon, 14 Aug 2006 15:15:55 +0200, Igor Kravtchenko
wrote: Hi!
I've looked at the way Twisted creates a process under Win32 and I've noticed that it uses the CreateProcess() function. The problem is it doesn't mention any creation flags (i.e.: it just passes 0) whereas here, we would need to pass DETACHED_PROCESS to avoid a new console to be created.
I would be interested to know what do you think about this? Does it seem to you a good idea?
Well, we do have a UNIX-specific argument to spawnProcess (usePTY), so I don't see why we couldn't have a Win32-specific argument as well. However, "win32flags" seems like a pretty vague name, especially since it could be CreateProcess's dwCreationFlags argument or STARTUPINFO's dwFlags attribute.
Also, depending on context, you might want CREATE_NO_WINDOW or DETACHED_PROCESS or possibly both.
I believe the right thing to do is to come up with some typical features of the Windows process environment and support them explicitly. I don't believe all the flags you can pass to CreateProcess are compatible with the way Twisted expects subprocesses to behave, and I am definitely sure that not all the things you can put in STARTUPINFO are.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
========== This email message and any attachments are for the sole use of the intended recipients and may contain proprietary and/or confidential information which may be privileged or otherwise protected from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipients, please contact the sender by reply email and destroy the original message and any copies of the message as well as any attachments to the original message.
participants (5)
-
glyph@divmod.com
-
Igor Kravtchenko
-
Jean-Paul Calderone
-
Michael Li
-
Thomas Jacob