Date: Fri, 19 Sep 1997 20:27:45 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: toor@dyson.iquest.net (John S. Dyson) Cc: nate@mt.sri.com, dyson@FreeBSD.ORG, karpen@ocean.campus.luth.se, current@FreeBSD.ORG Subject: Re: FYI: regarding our rfork(2) Message-ID: <199709192027.NAA01303@usr03.primenet.com> In-Reply-To: <199709191848.NAA02645@dyson.iquest.net> from "John S. Dyson" at Sep 19, 97 01:48:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The great strength about Unix is that another 'process' can'tt muck with
> > another 'processes' easily, and with threads I'd like to see this taken
> > to whatever extreme as possible given the constraints of implementation.
>
> The threads are a different issue. I don't disagree with the threads
> stacks being isolated for philosophical reasons -- however it is just
> wrong from a compatibility standpoint.
Exactly so. If you want this protection, implement using processes
instead of threads.
The problem is that I may pass auto variables between threads:
/* one of many threads with work to be done*/
thread1()
{
struct req my_request;
my_request.x = ...;
my_request.y = ...;
do_requeust( &my_request);
...
}
/* block calling thread until request completed*/
do_request( struct req *preq)
{
...
enqueue( preq);
...
while( preq->status != REQ_COMPLETE)
YIELD;
}
/* lives only to service requests*/
thread2()
{
struct req *preq;
for(;;) {
/* spin to get next work item*/
while( ( preq = dequeue()) == NULL)
YIELD;
/* service work item*/
...
/* mark work item completed*/
preq->status = REQ_COMPLETE;
}
}
I might do this, for example, if my work items were DNS lookups, etc.,
which had to be accomplished serially, or with some maximum concurrency
(say I start no more than 3 thread2's, and 10's of thread1's) because
of load characteristics.
In any case, if thread2 did not have access to thread1's stack, the
first time it tried to dereference preq, one of two things would
happen:
1) It would segfault because the page wasn't mapped
for thread2
2) It would dereference data from thread2's stack or
thread local storage instead of thread1's stack,
because that's the only way a page would be mapped
there in thread2's address space.
Either of these is bad.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709192027.NAA01303>