Re: MinGW open-process, take N

[Eli Zaretskii]

> From: Andy Wingo <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Sat, 16 Jul 2016 13:32:04 +0200
> 
> On Sat 16 Jul 2016 12:54, Eli Zaretskii <address@hidden> writes:
> 
> > Here's the first cut.  (I will rework it into git-format-patch form,
> > or commit and push myself, whatever is more convenient for you, as
> > soon as it is okayed for upstream.)
> 
> Looks good to me.

Thanks.

> Please configure your editor to not introduce tabs though

Sorry, not going to happen.  That's the default GNU indentation style.

> and remove tabs introduced in this patch.

The file had an enormous amount of tabs before my changes and my
changes added maybe 2 or 3.  Does it make sense to remove only those
few?

> I would just use scm_i_misc_mutex in this case though.
> 
>   scm_i_scm_pthread_mutex_lock (&scm_i_misc_mutex);
> 
>   /* do your thing */
> 
>   scm_i_pthread_mutex_unlock (&scm_i_misc_mutex);

OK, will do.

> >  . Once a subprocess is launched, its record sits in the procs[] array
> >    until deleted by waitpid, if it finds that the process has exited,
> >    or by kill.  If neither waitpid nor kill are called, the process's
> >    record will not be deleted, even though the process might be long
> >    dead.  This means that we leak handles, and the system gets process
> >    objects accumulated that it cannot recycle.  (This problem was
> >    already present in the previous version of the code, it is not new
> >    with the modified version.)  Can we be sure that a well-behaving
> >    Guile program will always call one of these 2 functions?  If not,
> >    how to prevent that in a well-behaving Guile program?  I guess at
> >    least close-port should try killing the process (if it doesn't
> >    already)?  Any other ideas?
> 
> This mirrors how POSIX works AFAIU.  Until you waitpid() on a child
> process, the PID isn't recycled, and the process exists in a "zombie"
> state.  So portable Guile programs will always waitpid() on processes
> they spawn.

Ah, good to know.

> Patch looks good to me, feel free to push after fixing tab problems and
> adding the mutex.

Will do, after we figure out the tricky tabs issue ;-)