Re: [9fans] vfork and paging

[presotto@plan9.bell-labs.com]

> the down side of this is that when debugging or inspecting the code,
> it's not immediately obvious whether a given function is running as a
> proc or a thread; e.g.  where shared access to a data structure might
> be a problem, or where a system call is intended to block all other
> threads.

It is indeed true that you have to know what your program does.  With
the thread library by default you share memory and fd's so accessibility
doesn't change twixt light and heavy threads, though syncronization problems
will be more likely to rear their ugly heads in the latter.

Blocking is a problem.  There's no particular reason to know whether a
thread will block or not if it calls a library routine that you didn't
write.  I haven't found it a problem, but that's largely because our
libraries are pretty simplistic so that I can guess if they would block
or not.

I wrote ndb/cs and ndb/dns before the thread library and it was a bit
of a pain.  I'le like to redo dns with it.