DragonFly BSD
DragonFly kernel List (threaded) for 2003-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Call for Developers! Userland threading


From: Craig Dooley <cd5697@xxxxxxxxxx>
Date: Tue, 22 Jul 2003 22:03:08 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 22 July 2003 09:30 pm, Matthew Dillon wrote:
> :>     hahahaha.  dragonthread... hahahaha.
> :>
> :>     lwkt_thread is good for userland.  I was going to call the kernel
> :>     thread's lwkt_thread but I decided to stick with the 5.x 'thread'
> :>     convention.
> :
> :light weight kernel thread _ thread?  what about
> :lwkt in kernel
> :lwut in userspace or just lwt?
>
>     Just lwkt_thread I think.  Sure there's a little pollution but it's
>     better to have pollution then confusion.
>
>     Besides, who says we wouldn't eventually be running whole kernels in
>     userland?  Then the userland LWKT's would deserve the 'K'.
>
> :The upcall system of KSE seems like the best way to preempt a process for
> :signals.  Even though there should only be one message port from what I
> :understand, what about 2, and having one do an upcall for things which
> : need immediate attention?  If im misunderstanding and every time a
> : message is receive it jumps to a handler just ignore me.
> :- -Craig
> :cd5697@xxxxxxxxxx
>
>     An upcall is probably the best way, though as with our IPI messaging
>     the kernel would not necessary *have* to always upcall, it could just
>     queue the returned message and let the userland pick it up in its own
>     good time.
So it sounds like theres going to have to be some user backing code to 
register a sort of handler.  Preemption is needed to allow signals to catch 
at all if you were caught in a tight loop (unless kernel takes over like 
KILL).  Should it be as complex as having the kernel creating a userland 
trapframe when its doing an "upcall" so the handler can decide what to do, 
and if it's not important, return to the interrupted thread?  Otherwise the 
kernel could probably have different paths for sending critical vs. 
non-critical messages to a process? It seems the first is going to have to be 
the approach for per process signals also.  I dont fully know the POSIX spec, 
but from my limited knowledge, it seems this would work.
- -- 
- -Craig
cd5697@xxxxxxxxxx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/HezcYXswu1EOVs0RAn7fAKCNjxgV4Igvq1U+elZJR7VntnMjqgCcDkPe
MhEmrhGfCSI6wbZT/x6Uxpk=
=p95/
-----END PGP SIGNATURE-----





[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]