Re: glib 2.3.3 and Windows

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

On 2004.02.29 18:34 Daniel K. O. wrote:
> J. Ali Harlow wrote:
>
> > 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
>
> (...)
>
> > My view is that I'd prefer B
>
>
> I'm working on an app that calls spawn*(), and then latter calls 
> cwait(). cwait() needs the value returned by spawn*(), not the pid. So, 
> if by some reason I try to use g_spawn*(), I'll have to add specific 
> #ifdef's to convert the pid to a handle? If so, I don't see too much 
> reason to use g_spawn*() if I need the process handle to cwait() later.

My view would be that mixing g_spawn and cwait is bad practice. I would
suggest that if there's some reason why you can't use the GLib API that
you stick to msvcrt and use spawn and cwait.

> By the way, g_spawn*() are always returning 0 (zero) as the "pid" 
> (handle?), that's why I had to use the pure spawn*(). Is it intentional? 
> I'm using Win 98 SE, with the latest DLLs from Tor's page.

Sounds like a bug to me; bugzilla.

--
J. Ali Harlow
ali juiblex co uk