[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MinGW open-process, take N
From: |
Eli Zaretskii |
Subject: |
Re: MinGW open-process, take N |
Date: |
Sat, 16 Jul 2016 15:08:25 +0300 |
> 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 ;-)
- Re: MinGW open-process, take N, (continued)
- 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, 2016/07/16
- Re: MinGW open-process, take N,
Eli Zaretskii <=
- 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