[Top][All Lists]

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

Re: MinGW open-process, take N

From: Andy Wingo
Subject: Re: MinGW open-process, take N
Date: Sat, 16 Jul 2016 13:32:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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.  Please configure your editor to not introduce tabs
though, and remove tabs introduced in this patch.

>  . Access to the procs[] array should be synchronized between
>    threads.  (Currently, MinGW builds of Guile don't work at all
>    unless built with --disable-threads, but AFAIR Mark wanted to have
>    the code thread-safe anyway.)  I guess this entails taking some
>    mutex before accessing the array, but I never wrote any such code
>    in Guile, so I'd appreciate to be pointed to some example, or to
>    have some boilerplate for that.

You can either use the scm_i_misc_mutex, or define your own.  If you
define your own you do:

  static scm_i_pthread_mutex_t process_table_lock = 

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);

>  . 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.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]