Re: glib 2.3.3 and Windows

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]