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.
>
> Besides, the spawn*() functions in the Microsoft runtime (the
> asynchronous variants) return HANDLEs, not pids. Thus the g_spawn*()
> functions do, too. I really don't see pids being much used in the
> Win32 API, it's always process HANDLEs that you handle.

Hi Tor,

I've just been talking about this very issue with Owen on IRC.

Leaving aside your point about ProcessID lifetime, which I'd need to 
check...

We've established that it would be good to be consistent with g_spawn_
which means either using handles in g_child_watch or changing g_spawn_
to use ProcessIDs.

Owen doesn't want to change the UNIX API after 2.4, so we need to make
a decision ASAP.

Owen sees three options:

<owen> A) We make GPid a handle, and add g_spawn_close_pid () which is a 
no-op
+on Unix, but that people porting Unix programs to Win32 can tell people to
+add to make there program stop leaking handles
<owen> B) We convert GPid and GSpawn to process ids, break existing
+win32-specific programs using GSpawn. Programs using only glib apis can't 
get
+things correct now anyways
<owen> C) We leave things as they are, with handles and no way not to leak,
+and fix for 2.6.

My view is that I'd prefer B and I'm happy to put together a patch by 
Monday
morning US time, but there's not enough time for any review to what would 
be
a major change. I think we have to go for A. The addition of a close_pid
function is a definite plus.

In the light of you comments on ProcessID lifetime, A would seem even 
better.

Some implementation comments:

configure.in needs to be changed to use 'void *' rather than HANDLE.
gmain.c needs to be changed to Duplicate the inbound handle so that the
caller can close theirs.

Cheers,

--
J. Ali Harlow
ali juiblex co uk