Fri 07 Oct 2016 01:54:44 AM UTC, comment #9:
No I think the function is WaitForSingleObject: https://msdn.microsoft.com/en-us/library/windows/desktop/ms687032(v=vs.85).aspx
|
Thu 06 Oct 2016 09:48:56 PM UTC, comment #8:
I'm not sure that WaitForInputIdle is what we are looking for as a replacement for waitpid, which is supposed to check the status of a process, typically to wait until it exits. It looks like WaitForInputIdle will tell you if a running process is idle and ready for input.
|
Thu 06 Oct 2016 07:43:43 PM UTC, comment #7:
For now, I checked in the following change:
http://hg.savannah.gnu.org/hgweb/octave/rev/610f88ed2b78
|
Thu 29 Sep 2016 07:20:39 PM UTC, comment #6:
Bleah! I think that Octave needs it's own function wrapper around specific MS API functions. This is what we do for popen2 where we call things like CreateProcess
Documentation for CreateProcess is here: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx.
It seems that maybe WaitForInputIdle might be a companion function: https://msdn.microsoft.com/en-us/library/windows/desktop/ms687022%28v=vs.85%29.aspx
This report clearly needs someone who both understands and is interested in the Windows API. I can't help much here because I code on Linux.
|
Thu 29 Sep 2016 06:58:57 PM UTC, comment #5:
Right, which is exactly what we used to do (waitpid callable but non-functional).
I did some very light searching on cwait / _cwait, and MSDN has a comment saying that it is only supported in CRT (console) applications, not in desktop applications (if anyone understands this jargon). This may mean that the gnulib waitpid wrapper is no good for our purposes and we may have to write our own wrapper around a function like WaitForSingleObject.
|
Thu 29 Sep 2016 06:10:16 PM UTC, comment #4:
@Mike: you're right. I just tried with version 4.0.2 that I had lying around.
One choice, if we can't get a gnulib wrapper to work, would be to simply let the child zombie army grow until it is finally reaped when Octave is closed.
|
Thu 29 Sep 2016 05:33:45 PM UTC, comment #3:
Well yes, in Octave 4.0.3 waitpid is not implemented (if I'm reading the source right).
Try
in Octave 4.0.3. The error message should say "waitpid: not supported on this system" and other than that the function will do nothing.
In Octave 4.2 it uses gnulib's waitpid wrapper around the _cwait function.
|
Thu 29 Sep 2016 11:42:31 AM UTC, comment #2:
Has the waitpip command from gnulib changed between Octave 4.0.3 and 4.2.0-rc2 ? (Octave 4.0.3 does not show those hang-ups, yet.) This might give an indication what to change (back)?
|
Thu 29 Sep 2016 03:59:39 AM UTC, comment #1:
Confirmed. I think the problem is that Windows just doesn't really have the same notion of children, process IDs, etc.
I played around with your script and waitpid, even when it returns, doesn't seem to do anything. I used the Process Monitor in Windows and I could see that there were still 'sort' processes left over.
What I did find that worked was using
At that point, I got no extra sort processes.
Maybe we need a waitpid process that is specifically written for Windows. The popen2 call is written for Windows, but waitpid is coming from gnulib.
|
Wed 28 Sep 2016 03:58:03 PM UTC, original submission:
I have observed that with the current Octave-4.2.0-rc2 the "test syscall" sometimes hangs under Windows OS. (With Octave 4.0.3 this still runs fine, its a regression)
I was able to reduce the underlying test code to a very simple example, that nearly always creates a "freeze in" of the Octave process on my Windows system:
I have the gut feeling, that this bug could have the same origin as several other bugs reported recently for 4.2.0-rc2 under Windows:
- a "hang-up" of "test copyobj", using gnuplot and the print command (bug #49179)
- occasional "hang-ups" of "test legend" (mentioned somewhere in the bug tracker)
- "hang ups" during compare_plot_demos with gnuplot (bug #49180)
The common point is that all those freezing tests call another Windows executable. Since all the other "freezes" have much more difficult underlying code, my hope is that this very short test script can help to remove all of those regression bugs at once.
|