Messages in this thread |  | | Subject | Re: SIGSTOP/CONT behaviour | Date | Thu, 27 Sep 2001 00:13:12 +0100 (BST) | From | Alan Cox <> |
| |
> If I send a SIGSTOP to another process, I can NOT rely on him not > running anymore after the kill syscall returns. Is that right? I think
Correct in specific narrow windows. A signal is an asynchronous event
> Additionally I could imagine there isn't even a guarantee that the > process won't execute userland code anymore in the case of SMP?
Yep.
> (What I wanted to do is stop several file serving daemons > (ftp,samba,netatalk) from fiddling with the filesystem while I traverse > through a file tree. I need to make sure I don't get files twice because > they have been moved while traversing and so on. I would not mind that > much about file *contents* changing, though. I'd welcome other > suggestions that don't imply changing the source code of these servers.)
I guess if you arent doing it often you could kill them then check they are in stopped state but thats icky.
Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |