[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: delete-process bug
From: |
Michaël Cadilhac |
Subject: |
Re: delete-process bug |
Date: |
Sun, 28 May 2006 23:36:54 +0200 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) |
address@hidden (Kim F. Storm) writes:
> address@hidden (Michaël Cadilhac) writes:
>
>> (Final ?) patch attached.
>
> Looks good to me!
>
> I wonder whether the pid should be added to deleted_pid_list if SIGCHLD is
> not defined? In that case, it would be a memory leak...
Oh, hmm... About memory leaks hrm...
In fact, there is already a configuration that would lead to the non
deletion of the PID from the list:
- Call to delete_process,
- Interrupted by a signal before inserting in deleted_processes_list ,
- Deletion from process_alist,
- Then delete_process continues by... inserting the dead PID in the
deleted_processes_list.
I forgot to tell about it in my previous post. Sorry.
Any idea for fixing this ? Putting the insertion in
deleted_processes_list BEFORE the Kill would limit this leak, but not
completely avoid it.
> But I also wonder if any of the async process stuff actually works
> without SIGCHLD ?!? Are there any systems which support async processes
> but don't have SIGCHLD?
Indeed, I don't know any system in which SIGCHLD is not defined and
that can use sub processes (are we talking about a one-process
system ?!).
But it would be cleaner, indeed, to define the whole thing iff SIGCHLD
is defined.
I modified the patch for that (including in sigchld_handler and so
because the list is not defined if SIGCHLD is not), and to make the
insertion in deleted_processes_list before the kill.
Index: src/process.c
===================================================================
RCS file: /sources/emacs/emacs/src/process.c,v
retrieving revision 1.481
diff -c -r1.481 process.c
*** src/process.c 8 May 2006 05:19:42 -0000 1.481
--- src/process.c 28 May 2006 21:35:32 -0000
***************
*** 778,783 ****
--- 778,793 ----
return proc;
}
+
+ #ifdef SIGCHLD
+ /* Fdelete_process promises to immediately forget about the process, but in
+ reality, Emacs needs to remember those processes until they have been
+ treated by sigchld_handler; otherwise this handler would consider the
+ process as being synchronous and say that the synchronous process is
+ dead. */
+ static Lisp_Object deleted_pid_list;
+ #endif
+
DEFUN ("delete-process", Fdelete_process, Sdelete_process, 1, 1, 0,
doc: /* Delete PROCESS: kill it and forget about it immediately.
PROCESS may be a process, a buffer, the name of a process or buffer, or
***************
*** 799,804 ****
--- 809,820 ----
}
else if (XINT (p->infd) >= 0)
{
+ #ifdef SIGCHLD
+ /* No problem storing the pid here, as it is still in Vprocess_alist.
*/
+ deleted_pid_list = Fcons (make_fixnum_or_float (p->pid),
+ /* GC treated elements set to nil. */
+ Fdelq (Qnil, deleted_pid_list));
+ #end
Fkill_process (process, Qnil);
/* Do this now, since remove_process will make sigchld_handler do
nothing. */
p->status
***************
*** 6373,6378 ****
--- 6389,6405 ----
/* Find the process that signaled us, and record its status. */
+ #ifdef SIGCHLD
+ /* The process can have been deleted by Fdelete_process. */
+ tail = Fmember (make_fixnum_or_float (pid), deleted_pid_list);
+ if (!NILP (tail))
+ {
+ Fsetcar (tail, Qnil);
+ goto sigchld_end_of_loop;
+ }
+ #endif
+
+ /* Otherwise, if it is asynchronous, it is in Vprocess_alist. */
p = 0;
for (tail = Vprocess_alist; GC_CONSP (tail); tail = XCDR (tail))
{
***************
*** 6424,6431 ****
EMACS_SET_SECS_USECS (*input_available_clear_time, 0, 0);
}
! /* There was no asynchronous process found for that id. Check
! if we have a synchronous process. */
else
{
synch_process_alive = 0;
--- 6451,6458 ----
EMACS_SET_SECS_USECS (*input_available_clear_time, 0, 0);
}
! /* There was no asynchronous process found for that pid: we have
! a synchronous process. */
else
{
synch_process_alive = 0;
***************
*** 6442,6447 ****
--- 6469,6478 ----
EMACS_SET_SECS_USECS (*input_available_clear_time, 0, 0);
}
+
+ sigchld_end_of_loop:
+ ;
+
/* On some systems, we must return right away.
If any more processes want to signal us, we will
get another signal.
***************
*** 6843,6848 ****
--- 6874,6882 ----
FD_SET (0, &input_wait_mask);
Vprocess_alist = Qnil;
+ #ifdef SIGCHLD
+ deleted_pid_list = Qnil;
+ #endif
for (i = 0; i < MAXDESC; i++)
{
chan_process[i] = Qnil;
***************
*** 6981,6986 ****
--- 7015,7023 ----
staticpro (&Qlast_nonmenu_event);
staticpro (&Vprocess_alist);
+ #ifdef SIGCHLD
+ staticpro (&deleted_pid_list);
+ #endif
DEFVAR_BOOL ("delete-exited-processes", &delete_exited_processes,
doc: /* *Non-nil means delete processes immediately when they
exit.
--
| Michaël `Micha' Cadilhac | Pour les 35-40 ans, l'humour |
| Epita/LRDE Promo 2007 | c'est une plus-value. |
| http://www.lrde.org/~cadilh_m | -- Guillaume L. |
`-- - JID: address@hidden --' - --'
pgpxdmNqdpsAt.pgp
Description: PGP signature
- Re: delete-process bug, (continued)
- Re: delete-process bug, Michael Mauger, 2006/05/26
- Re: delete-process bug, Michaël Cadilhac, 2006/05/27
- Re: delete-process bug, Stefan Monnier, 2006/05/27
- Re: delete-process bug, Michaël Cadilhac, 2006/05/27
- Re: delete-process bug, Michaël Cadilhac, 2006/05/28
- Re: delete-process bug, Stefan Monnier, 2006/05/28
- Re: delete-process bug, Michaël Cadilhac, 2006/05/28
- Re: delete-process bug, Stefan Monnier, 2006/05/28
- Re: delete-process bug, Michaël Cadilhac, 2006/05/28
- Re: delete-process bug, Kim F. Storm, 2006/05/28
- Re: delete-process bug,
Michaël Cadilhac <=
- Re: delete-process bug, Stefan Monnier, 2006/05/28
- Re: delete-process bug, Michaël Cadilhac, 2006/05/29
- Re: delete-process bug, Kim F. Storm, 2006/05/29
- Re: delete-process bug, David Kastrup, 2006/05/29
- Re: delete-process bug, Eli Zaretskii, 2006/05/29
- Re: delete-process bug, Eli Zaretskii, 2006/05/29
- Re: delete-process bug, Kim F. Storm, 2006/05/29
- Re: delete-process bug, Eli Zaretskii, 2006/05/29
- Re: delete-process bug, Eli Zaretskii, 2006/05/28
- Re: delete-process bug, Kim F. Storm, 2006/05/29