> From: Andy Wingo <wi...@pobox.com> > Cc: m...@netris.org, l...@gnu.org, guile-devel@gnu.org > Date: Sat, 16 Jul 2016 13:32:04 +0200 > > On Sat 16 Jul 2016 12:54, Eli Zaretskii <e...@gnu.org> 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 ;-)