Date: Fri, 8 Mar 2002 00:34:16 -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.0203080017330.46841-100000@InterJet.elischer.org> In-Reply-To: <15496.23508.148366.980354@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Mar 2002, Nate Williams wrote: > > > > 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. > > However, control is returned to the parent process (such as the shell), > correct? Something is returning to userland. A signal. at the time that the process has it's "Im stopped' bit set. (and wait() returns if you did one) > > > 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). This is when the signal is sent. > > I'm with you so far. (Although stating the 'the timer keeps running' is > misleading, since the 'timer' isn't created on a per-process basis). There is a timeout entry for it ok? > > > 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. > > Still with you. > > > Until CONT is received it is holding resources etc. > > Hopefully not. :) Hopefully not contentious resources but still some resorces, (e.g. anything it malloc'd on the way in). > > > 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. > > Exactly. > > > 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. When I say "no other action" I don't include sending the signal which still happens (to the parent). > > In effect, the context is actually still active inside the kernel, even > though the userland process is never given notice. I could see this > having *really* strange effects for things that do network I/O. > Often-times I've suspended processes inside of gdb so I could set > breakpoints knowing full well that *NOTHING* was going to happen, even > if I was in the middle of a system call. You'd be surprised then because once the send() is done, the network IO will happen independently of the process. this is no different. from the time you do the ^Z to the time the syscall thinks of returning is how long? If you say 3 seconds then all that is different is that in my case the data has been taken off the queue but previously it would have still been on the queue, but since the process is stopped, who can tell? In fact if the data was already present then sleep(0 would have never been called, so the blocking would (even now) happen at the user boundary. All I'm doing is making it consitent. > > I'm still not getting a warm fuzzy that allowing the userland context to > complete and then block at the userland boundary is a good idea. I'm > not saying it's a bad idea, but I'm almost positive there are gremlins > hiding in the details here. :) Userland context? where does userland context come into it? I'm talking about when a syscall blocks after or shortly before a SIGSTOP is received. > > > 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. > > In effect, you're avoiding moving the process from the STOPPED queue and > back to the SLEEP queue. I'm allowing it to STAY in the SLEEEP queue, knowing that when it decides to continue, it can not get back to userland. because I've blocked that road with a fallen tree. > > > 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. > > Right, but currently, stopping a process/thread stops it *everywhere*, > including the kernel. We're changing something that has been done this > way for a very long time, and the POLA may come back and bite us. > No it doesn't stop it everywhere. if you have not set PCATCH or if you do not sleep you will proceed forwards oblivious of the pending signal, until you try return to user land, at which point you will be stopped, just as I am suggesting, except I am sugesting that we should ALWAYS stop it there. > > 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. > > Except that there are now locking issues since the 'other thread' is now > messing around with parts of the thread that may be in use by the thread > itself. (*ick*) > No, it is in the proc struct. All threads sharing the same proc see the same bit. > > 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. > > I'm sure you have, but probably not intentionally. There is almost > certainly software that relies on the existing behavior, and will behave > differently (perhaps not wrong) with the aboved described changes. > > > 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. > > Maybe a sysctl to turn it off/on? However, I suspect this would be > *really* hard to keep both ways going. > > Thanks for the more detailed explanation!! > > > 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.0203080017330.46841-100000>