[wpkg-users] [Bug 155] stdout/stderr flush code causes some commands to hang

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=155


Rainer Meier <r.meier at wpkg.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.meier at wpkg.org
             Status|NEW                         |ASSIGNED




--- Comment #1 from Rainer Meier <r.meier at wpkg.org>  2009-04-19 11:06:47 ---
Hi Jason,

I can confirm that you're right. As soon as the AtEndOfStream property (it's
not a function/method). It seems to cause the forked CMD not to exit and keeps
waiting for it to be closed. When it exits (manually or by implicit exit) then
the parent process continues too.

Yesterday I spent half a day to find a way to flush the output AND allow
forking processes. However I did not yet succeed. Personally from my (mainly
Unix) experience I would call it a bug but probably it's a "design feature" of
Windows.

Currently I am thinking about removing the flush code again since this behavior
is really unexpected. If I want to run a sub-command using "start" (without
/wait parameter) then I would expect that my parent script (the one calling
"start") exits immediately.

So let me investigage a bit further and then I will either revert the changes
to flush the output (which instead would make commands with huge output of
several kB to "hang") or to implement a working fix. As this exec() method is
quite a crucial part of WPKG it's really important for a fix to work properly
and in all environments. So I don't want to include any dirty workarounds and
tricks which might fail in some environments. Then I would prefer not to flush
the output and just document that the command run should not print more than xy
kB on the console. I think usually no installer is doing this anyway and if it
does it might be wrapped with a CMD script or its output being redirected to
NUL.


-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.