Date: Thu, 7 Mar 2002 22:06:25 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Nate Williams <nate@yogotech.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <Pine.BSF.4.21.0203072034130.46043-100000@InterJet.elischer.org> In-Reply-To: <15496.14272.351722.199146@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Mar 2002, Nate Williams wrote: > > > > My suggestion is to stop making STOP type signals an exception, > > > > because it should not be necessary to stop them in the middle of a > > > > syscall, just stop them from getting back to userspace. > > > > > > What about when you suspend a process in the middle of read/write, which > > > are syscalls? This kind of behavior is *extremely* common-place > > > > hmm can you explain what you mean? I can't think of anything > > that would change.. > > 'read' is a system call. If a program is sitting in a read (waiting for > user input), this system call must be interruptible. > or not, either way it doesn't matter. The important thing is that no matter what happens it doesn't return to the user while the user is suspended. currently: If the sleep is interruptable (PCATCH) then the code will receive the STOP. It will not wake up, but transition into the STOPPED state (the timer keeps running however). When the timer terminates, or the data arrives it attempts to wake up the process, but noticing it is STOPPED, doesn't actually put it on the run queue. Later when the CONT is received, it is put on the run queue, reads the data (or not) and returns to user mode. Until CONT is received it is holding resources etc. If the CONT happens before the data arrives or the timeout expires the process is put back into SLEEP mode.. When the data arrives or the timeout happens, it doesn't notice it was STOPPED before. My suggestion: If the sleep is interruptable (PCATCH), a flag is set saying a STOP was seen, no other action. When the data arrives or the timeout expires, it reads the data (or not) and proceeds to the user boundary. It waits there for the CONT signal. If the CONT happens before the data arrives or the timeout expires the flag is simply cleared again. It doesn't make such a huge difference now but when there are multiple threads in a process, being able to report to the controlling shell, or the debugger "OK its STOPPED" as soon as I can prove that all threads are in the kernel and not in user space makes a big difference. Also, the bit for "this process is STOPPING" can be set by another thread and all threads will see it. Saving me from having to run around all threads and do all sorts of stuff with each. I don't necessarily want to do this in -current on it's own. I have code that does this in the KSE diffs. I want to know if I've forgotten anything because when I commit the KSE diffs I don;t want to discover I've broken everything. it ispossible I might be able to commit this change separatly before hand so that it's an Isolated change however and if I can I might think about doing that. That way we introduce one change at a time. > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0203072034130.46043-100000>