[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 =
SCM_I_PTHREAD_MUTEX_INITIALIZER;
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.
Andy
- MinGW open-process, take N, Andy Wingo, 2016/07/11
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/12
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/12
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/12
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/14
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/14
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/14
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/14
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/14
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/16
- Re: MinGW open-process, take N,
Andy Wingo <=
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/16
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/16
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/16
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/23