[9fans] p9p threadpin() / threadunpin() ?

[9fans] p9p threadpin() / threadunpin() ?

[Venkatesh Srinivas]

Hi,

I noticed that p9p has threadpin() and threadunpin() in its thread
library... they claim to make the current thread the only one runnable
in this proc. I'm failing to see the purpose of these... a thread is
not subject to preemptive scheduling, it can achieve the same effect
by not calling yield(), right?

Also, these two functions aren't in p9's libthread... is there any
reason why not (assuming those two have a purpose)?

Thanks,
-- vs

Re: [9fans] p9p threadpin() / threadunpin() ?

[Russ Cox]

On Wed, Jul 22, 2009 at 9:04 PM, Venkatesh Srinivas<me@acm.jhu.edu> wrote:
> I noticed that p9p has threadpin() and threadunpin() in its thread
> library... they claim to make the current thread the only one runnable
> in this proc. I'm failing to see the purpose of these... a thread is
> not subject to preemptive scheduling, it can achieve the same effect
> by not calling yield(), right?
> Also, these two functions aren't in p9's libthread... is there any
> reason why not (assuming those two have a purpose)?

Yes and yes.  Unfortunately, it is sometimes impossible to
avoid calling yield.  On Plan 9, the graphics library uses
writes to /dev/draw and the kernel manages simultaneous
access by multiple threads.  In Plan 9 port, everything
happens in user space and there are qlocks to help
make things thread safe.  Unfortunately the fact that the
qlocks can reschedule inside a proc makes them different
from a write system call.  Rather than rewrite all the draw
code to remove the assumption that /dev/draw writes do
not reschedule, I made the simulation of /dev/draw
also not reschedule.  It is not a good approach in general,
which is why the functions are undocumented.

http://code.swtch.com/plan9port/src/tip/src/libdraw/drawclient.c#cl-189

Russ