On 23-Jul-01 Julian Elischer wrote:
> Why does the mutex not link blocked processes though the
> sleep queue linked list entry? Why does it use the run queue entry?
> In KSEs the sleep queue and run queue enties go into different
> sub structures and ahve different types so this breaks...
> do I need to do something sleazy or can I just link them together using the
> equivalemt of the p_slpq entry?
You can block on a mutex when processing signals in the catch case in msleep()
after you have put the process on the sleep queue:
int
msleep(ident, mtx, priority, wmesg, timo)
{
...
p->p_wchan = ident;
p->p_wmesg = wmesg;
p->p_slptime = 0;
p->p_pri.pri_level = priority & PRIMASK;
CTR5(KTR_PROC, "msleep: proc %p (pid %d, %s) on %s (%p)", p, p->p_pid,
p->p_comm, wmesg, ident);
TAILQ_INSERT_TAIL(&slpque[LOOKUP(ident)], p, p_slpq);
...
/*
* We put ourselves on the sleep queue and start our timeout
* before calling CURSIG, as we could stop there, and a wakeup
* or a SIGCONT (or both) could occur while we were stopped.
* A SIGCONT would cause us to be marked as SSLEEP
* without resuming us, thus we must be ready for sleep
* when CURSIG is called. If the wakeup happens while we're
* stopped, p->p_wchan will be 0 upon return from CURSIG.
*/
if (catch) {
CTR3(KTR_PROC, "msleep caught: proc %p (pid %d, %s)", p,
p->p_pid, p->p_comm);
p->p_sflag |= PS_SINTR;
mtx_unlock_spin(&sched_lock);
PROC_LOCK(p);
sig = CURSIG(p);
mtx_lock_spin(&sched_lock);
PROC_UNLOCK_NOSWITCH(p);
...
If that proc_lock blocks then we don't want to clobber the sleep queue.
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
