Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 08 Dec 1999 20:05:08 -0500
From:      "Daniel M. Eischen" <eischen@vigrid.com>
To:        Julian Elischer <julian@whistle.com>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: Threads discussion
Message-ID:  <384F0044.3292DAC@vigrid.com>
References:  <Pine.BSF.4.10.9912081636000.23315-100000@current1.whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote:
> 
> On Wed, 8 Dec 1999, Daniel M. Eischen wrote:
> 
> > Julian Elischer wrote:
> > >
> > > is not dead.. we're all catching our breath!
> > >
> > > Tomorrow at the Bay Area Freebsd Users Group (BAFUG)
> > > there will be a food fight over threads kernel support.
> > > Anyone within driving range is urged to attend.
> >
> > Hey, this isn't fair!
> 
> :-)
> just chance..
> Alfred perlstein will be there too.

I miss out on all the fun :(

> I think we'll just be swapping ideas. but we MAY be able to get the
> speaker phone hooked in..
> wouldn't that be interesting?

Yes :)

> I'm not sure how I'd get a conference call set up but that may even be a
> possibility. (!)

Well, if you need another person on your async call-gate/SA side,
hook me up.
 
> >
> > BTW, I don't think the kernel can always know if a subprocess
> > is in a notification upcall by looking at the user stack
> > pointer.  The upcall notification may be temporarily switched
> > to resume a preempted thread holding a critical resource.
> 
> I wasn't thinking of just upcalls but it may be important to know
> whether it is in the scheduler when responding to a pagefault.

Yes, I agree.

> I think page faults in the scheduler should just block.

Hmm, that's certainly the easy route to take.  But it still might
be possible for another scheduler to make progress.  If you have
user-level scheduling queues for each subprocess or if the fault was
on the scheduler stack, for instance.  Just thinking out loud...
Details that can be worked out later, I suppose.

Dan Eischen
eischen@vigrid.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?384F0044.3292DAC>