Re: glib 2.3.3 and Windows

On 2004.02.29 21:39 Daniel K. O. wrote:
J. Ali Harlow wrote:

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.

Why is it a bad pratice? I need cwait() until the process finishes. Should I use #ifdef's and add Linux and Win32 specific code? And if it is a bad pratice, why is g_spawn*() returning a pid anyways? Is there a GLib function that uses this returned pid? If not, the native spawn*() functions seem more portable than g_spawn*() (unless of course you guys provide functions like g_cwait()).

First, just so there's no confusion - I'm just a Gtk+ user, nothing more.

The reason I think it's bad practice is that there's a good chance that
cwait will continue to work with spawn no matter what else happens, but
there's less chance that it will continue to work with g_spawn. If GLib
did decide to move to ProcessIDs that would be a case in point.

The discussion we're having revolves around a new API like g_cwait known
as g_child_watch.

By the time 2.4 is released (and bugs fixed) I would hope that you would
have the choice to either use g_spawn and g_child_watch _or_ to use ifdef
WIN32 if the new API isn't powerful enough for you. I believe there will
always be occasions where the later is necessary.


J. Ali Harlow
ali juiblex co uk

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