Re: glib 2.3.3 and Windows

["J. Ali Harlow" <ali juiblex co uk>]

On 2004.02.29 17:41 Tor Lillqvist wrote:
> J. Ali Harlow writes:
>  > Personally I advocate making GPid hold ProcessIDs anyway for reasons I
>  > go into in my comments to 50296. I'd appreciate your views.
>
> You say: "These [..] don't have a lifetime to manage". Isn't the exact
> opposite true? Pids might get reused without you noticing, might they
> not? If you have a HANDLE to a process, you are guaranteed that it
> refers to the same process (which of course might have died and become
> a zombie in the meantime) until you CloseHandle() it.

Having had a chance to have a play with this, let me add some further
comments:

Firstly, you're right - MS-Windows does reuse ProcessIDs much sooner than
UNIX. I can't tell what the algorithm is but creating and killing processes
in quick succession seems to have a very high probablity of PID reuse 
within
three or four children, which is a major disadvantage to using them.

Secondly, you make an excellent point re. zombie processes. The platform 
SDK
says that PIDs are only valid until process termination. If that means, as
you suggest, that it's not possible to use OpenProcess on a zombie process,
then that's another major disadvantage.

Thus I have to conclude that HANDLEs are the only sensible choice. Sorry
for wasting your time.

That means that we just need to decide the best way to use them. I think
Owen's suggestion of a g_spawn_close_pid() function is the best answer.

If I don't hear any objections, I'll put together a patch to implement
this along with the other bits-n-bobs that are necessary first thing
Monday morning so it will be available for Owen to sneak into 2.3.4
when the USA wakes up.

Proposed changes:

configure.in: HANDLE -> 'void *'
gmain.c!g_child_watch_source_new: Add DuplicateHandle
gaim.c!g_child_watch_dispatch: Add CloseHandle
child-test.c: Move CloseHandle to immediatetly after child_watch_source_new
docs for child_watch_source_new: Add comment explaining that caller is
  resonsible for closing the passed in pid (and pointing out 
g_spawn_close_pid)
  and that GLib is responsible for closing the internal pid with a note 
that
  the value of GPid passed to the callback function may not be the same as
  originally passed to g_child_watch_source_new().
New function g_spawn_close_pid(): NOP under UNIX, CloseHandle() under 
WIN32.
g_spawn_* changed to use GPid.
docs for g_spawn_* changed to explain that caller is responsible for 
closing
  GPids with g_spawn_close_pid().

and anything else I haven't thought of yet...

Cheers,

--
J. Ali Harlow
ali juiblex co uk