Opened 3 years ago

Last modified 3 years ago

#6781 defect new

twisted reactor.spawnProcess opens an unwanted console on windows when cx_freeze'd

Reported by: gianmt Owned by:
Priority: normal Milestone:
Component: core Keywords: windows
Cc: gianmt Branch:
Author:

Description

when I run the code from a console (on Windows) the child process runs without opening another console, but when I run the code from the cx_freeze'd app another console opens.

I found this old thread where was suggested to use FreeConsole(), it will flash the console on screen for a blink but I can eventually live with it, unfortunately if i understood correctly it should be called from the child process.

http://twistedmatrix.com/pipermail/twisted-python/2007-February/014738.html

I also found this ticket (7yo) on a re-factoring of the whole spawnProcess on windows but apparently it never happened:

http://twistedmatrix.com/trac/ticket/2415

I have no control over the code of the child process, so doing something there is unfortunately not an option, but even if I did the process I'm spawning it's a console app and I believe FreeConsole() could not be called there or the process will terminate.

Glyph @stackoverflow suggested the following:


What happens when you run the code from the GUI with Python, but without cx_Freeze involved? You should be able to test this if you have Python installed by simply putting your code into a .pyw file and double-clicking on it in Explorer.

If this still pops up a console window when you run your subprocess, then this is totally a bug in Twisted and you should file it as such. Eric's answer in that mailing list message is wrong; if you want to spawn processes with spawnProcess they definitely shouldn't be popping up random console windows.


I can confirm that cx_freeze isn't doing anything wrong, even using pythonw spawns a console window, having a useConsole flag for spawning processes on windows would be great.

Change History (5)

comment:1 Changed 3 years ago by exarkun

How is it determined whether a console is "unwanted" or not?

comment:2 Changed 3 years ago by gianmt

  • Summary changed from twisted reactor.spawnProcess opens an unwanted console when cx_freeze'd to twisted reactor.spawnProcess opens an unwanted console on windows when cx_freeze'd

While running a GUI app do you want a useless console opening in front of your app without anything print on it (and you cannot interact with it as well), that stays open until the process finishes, or flashes on screen for a blink if the spawned process immediately terminates.

If the answer to the above is yes, then you want it (you should really really ask yourself why), but I have the feeling that the answer would be "no I don't want it" 100% of the times. In this case a flag useConsole=False which uses the CREATE_NO_WINDOW CreateProcess() flag would be awesome, don't you think?

comment:3 Changed 3 years ago by gianmt

  • Cc gianmt added

comment:4 Changed 3 years ago by exarkun

I'm sorry if the question was unclear. What I was trying to ask is how the implementation of IReactorProcess.spawnProcess can determine whether the console should be left alone or suppressed. I wasn't trying to ask about how the application developer might make this decision.

a flag useConsole=False which uses the CREATE_NO_WINDOW CreateProcess() flag would be awesome, don't you think?

I don't know. This introduces additional divergence into this interface between POSIX and Windows. For an API that is supposed to be cross-platform, divergence is a bad thing.

This is not a suggestion that an unwanted, unsuppressable console window is not a bad thing - I'm just pointing out that there might be undesirable traits of a new useConsole flag as well.

comment:5 Changed 3 years ago by gianmt

Sorry I misunderstood your question then, I was just trying to better explain the unwanted behavior, one thing that could be done is make usePTY working on windows the same as it does on *NIX, it could be carefully explained in the docs the usage.

I know it's not ideal since on windows PTY does not make much sense, but the API would be consistent on both platforms.

Note: See TracTickets for help on using tickets.