cv_timedwait() & exiting procs

John Baldwin jhb at FreeBSD.org
Mon Mar 31 12:51:01 PST 2003


On 31-Mar-2003 Andrew Gallatin wrote:
> 
> 
> FreeBSD's cv_timedwait() function helpfully notices that a process is
> exiting and returns EWOULDBLOCK if it is.
> 
> However, if you call cv_timedwait() in the context of a process which
> is already exiting, you always get back EWOULDBLOCK, regardless of
> whether or not the timeout expired.  Similarly for the cv_wait_sig()
> and cv_timedwait_sig(), except they set EINTR.
> 
> Does anyone else consider this behaviour to be a bug?  I think it
> should only return EWOULDBLOCK/EINTR because a process is exiting if
> the process wasn't already exiting when it entered the cv_*wait*
> routine, but perhaps I'm misguided...

I think you are referring to these changes?

revision 1.23
date: 2002/06/29 17:26:18;  author: julian;  state: Exp;  lines: +76 -13
Part 1 of KSE-III

The ability to schedule multiple threads per process
(one one cpu) by making ALL system calls optionally asynchronous.
to come: ia64 and power-pc patches, patches for gdb, test program (in tools)

Reviewed by:    Almost everyone who counts
        (at various times, peter, jhb, matt, alfred, mini, bernd,
        and a cast of thousands)

        NOTE: this is still Beta code, and contains lots of debugging stuff.
        expect slight instability in signals..

Things like:

@@ -293,6 +328,8 @@
                        rval = ERESTART;
        }
        PROC_UNLOCK(p);
+       if (p->p_flag & P_WEXIT)
+               rval = EINTR;
 
 #ifdef KTRACE
        if (KTRPOINT(td, KTR_CSW))
@@ -363,6 +400,8 @@
                mi_switch();
        }
 
+       if (td->td_proc->p_flag & P_WEXIT)
+               rval = EWOULDBLOCK;
        mtx_unlock_spin(&sched_lock);
 #ifdef KTRACE
        if (KTRPOINT(td, KTR_CSW))
@@ -450,6 +488,9 @@
        }
        PROC_UNLOCK(p);
 
+       if (p->p_flag & P_WEXIT)
+               rval = EINTR;
+
 #ifdef KTRACE
        if (KTRPOINT(td, KTR_CSW))
                ktrcsw(0, 0);

I guess this has something to do with single threading?  If so it
seems broken since it should only affect the singlethreading case
while you are actually doing singlethreading.  Maybe Julian can help
fix it?

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


More information about the freebsd-arch mailing list