Adrian,
sorry I haven't commented earlier; I've been away from email for the
last few days.
>>>>> "Craig" == Craig Lanning
<CraigL(a)DyCon.com> writes:
Craig> This doesn't work for me on Win98 (mingw32). It actually
Craig> makes things worse.
Hello Craig, thanks for the feedback.
I am working on an improved patch.
The issue seems to be that the process may be gone before my patch
even gets the process handle from the process ID.
You've solved this problem by opening a handle on the process, which
means that the process will stick around until you close the handle.
Your change to wait_for_termination() is ugly but I can't think of any
other way round the problem of dealing with call_process_cleanup(). You
should probably change wait_for_termination() so that on win32 its
argument is "phandle" rather than "pid".
How about using WaitForSingleObject(pid, 1/10s) instead of
GetExitCodeProcess() in your do...while loop in wait_for_termination().
That might make XEmacs to use a lot less CPU and let its child process
exit more quickly. You'll obviously still need to call
GetExitCodeProcess() once after the child has really terminated.
On Windows 95/98 process IDs are negative(!) which screws up in a call
to make_int() in Fcall_process_internal() by blowing the 30(?) bit lisp
integer size. There's a nasty hack in create_child at line 450 of
ntproc.c to get round this by making the PID positive. The problem that
Craig was experiencing with your original patch may have been due to the
fact that you weren't renegativising the PID in the call to
OpenProcess(). Your code still has this problem. You either have to
include ntheap.h and make the pid passed to OpenProcess negative if
(os_subtype==OS_WIN95), or you have to come up with a better general
solution to the negative pid problem.
Jonathan.
--
Jonathan Harris | jhar(a)tardis.ed.ac.uk
London, England | Jonathan.Harris(a)symbian.com