> Date: Fri, 29 Jun 2001 18:33:52 +0300
> From: Peter Pentchev <[EMAIL PROTECTED]>
>
> > > The threads scheduler is in user space. It converts a
> > > blobking call into a non-blocking call plus a context
> > > switch. THus blocking _IS_ a problem.
> >
> > Bad wording on my part again; perhaps "a problem that I [think
> > that] I have handled" is better. I'm use nb calls if possible;
> > else I have a long-running worker thread.
>
> I hope you understand that when the worker thread blocks,
> it's the process that blocks, and none of the other threads
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes.
> it's the process that blocks, and none of the other threads
^^^^^^^^^^^^^^^^^^^^^^^^^
> can run until the end of the syscall.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Again, I am *not* using pthreads. Worker thread = totally separate
process, created via rfork(2). One process blocks, others continue
running.
To reiterate: I'm *not* using pthreads or libc_r. I wanted to check my
work, and began looking at libc_r code, under the faulty ass-umption that
it ran multiple processes.
Now that I know that threads are implemented in a single process, and that
blocking calls are thunked to non-blocking calls, the locking that I
originally questioned makes sense.
Eddy
---------------------------------------------------------------------------
Brotsman & Dreger, Inc.
EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
---------------------------------------------------------------------------
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots. Do NOT
send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
