| From | Sent On | Attachments |
|---|---|---|
| Julian Elischer | Oct 31, 1999 11:57 am | |
| Julian Elischer | Oct 31, 1999 1:15 pm | |
| Kris Kennaway | Oct 31, 1999 2:00 pm | |
| Amancio Hasty | Oct 31, 1999 2:11 pm | |
| Julian Elischer | Oct 31, 1999 2:38 pm | |
| Kris Kennaway | Oct 31, 1999 3:09 pm | |
| Nate Williams | Oct 31, 1999 3:40 pm | |
| Daniel Eischen | Oct 31, 1999 3:43 pm | |
| Daniel Eischen | Oct 31, 1999 3:53 pm | |
| Daniel C. Sobral | Oct 31, 1999 4:48 pm | |
| Nate Williams | Oct 31, 1999 4:54 pm | |
| Julian Elischer | Oct 31, 1999 5:08 pm | |
| Peter Jeremy | Oct 31, 1999 5:15 pm | |
| Nate Williams | Oct 31, 1999 5:15 pm | |
| Julian Elischer | Oct 31, 1999 5:41 pm | |
| Julian Elischer | Oct 31, 1999 5:49 pm | |
| Julian Elischer | Oct 31, 1999 6:16 pm | |
| Nate Williams | Oct 31, 1999 6:19 pm | |
| Nate Williams | Oct 31, 1999 6:20 pm | |
| Amancio Hasty | Oct 31, 1999 6:31 pm | |
| Julian Elischer | Oct 31, 1999 6:44 pm | |
| Daniel Eischen | Oct 31, 1999 7:01 pm | |
| Nate Williams | Oct 31, 1999 7:02 pm | |
| Daniel Eischen | Oct 31, 1999 7:14 pm | |
| Daniel Eischen | Oct 31, 1999 7:16 pm | |
| Daniel Eischen | Oct 31, 1999 7:46 pm | |
| Nate Williams | Oct 31, 1999 8:12 pm | |
| Daniel Eischen | Oct 31, 1999 8:53 pm | |
| Marcel Moolenaar | Nov 1, 1999 1:56 am | |
| Randell Jesup | Nov 1, 1999 3:12 am | |
| Nate Williams | Nov 1, 1999 7:28 am | |
| Justin T. Gibbs | Nov 1, 1999 9:05 am | |
| Nate Williams | Nov 1, 1999 11:07 am | |
| Justin T. Gibbs | Nov 1, 1999 11:14 am | |
| Peter Dufault | Nov 1, 1999 11:36 am | |
| Daniel Eischen | Nov 1, 1999 11:54 am | |
| Nate Williams | Nov 1, 1999 12:01 pm | |
| Nate Williams | Nov 1, 1999 12:02 pm | |
| Nate Williams | Nov 1, 1999 12:16 pm | |
| Daniel Eischen | Nov 1, 1999 12:36 pm | |
| Daniel Eischen | Nov 1, 1999 12:52 pm | |
| Nate Williams | Nov 1, 1999 12:59 pm | |
| Peter Dufault | Nov 1, 1999 1:04 pm | |
| Julian Elischer | Nov 1, 1999 1:18 pm | |
| Peter Dufault | Nov 1, 1999 1:22 pm | |
| Jacques Vidrine | Nov 1, 1999 2:43 pm |
| Subject: | Re: Threads models and FreeBSD. | |
|---|---|---|
| From: | Nate Williams (na...@mt.sri.com) | |
| Date: | Oct 31, 1999 5:15:57 pm | |
| List: | org.freebsd.freebsd-arch | |
3/ Inability of one thread to block aother thread unless they are intentionally synchronising.
I think this can be dropped, since it's both confusing and almost contradictory. There is no such way to 'block' a regular process, although one can stop it in Unix, so the issue of blocking implies a blocking on something, which is allowed.
What this means is that if one thread does a read() and blocks, the other threads don't all block.
maybe I should reword it to: "Inability of one thread to unwittingly block another thread during normal operations" ?
How about the abilty for multiple threads to execute at the same time? :)
The double negative implies that we would not add functionality that might be desired.
4/ All threads see the same address space (exactly).
5/ All threads share the same file resources.
All threads share all the same resources (except for thread-specific stack).
Well they can see all the other stacks, they just don't use them as the stack. How would you better word that?
The resources are *all* shared (not just file resources), but each thread has it's own thread-specific stack.
Richard seaman's work is available. it can be used prety much without change.. Do we want to do that?
Who's we white-man? (That's a very American joke for our international readers). I'd like to here from the 'kernel architects', who have been completely silent on the topic of kernel threads up til this point. (And not just in the context of this discussion, they've been mostly silent for months, if not years on this topic, except to say that they don't like Richard's solution..)
Another thing I'd like to add to the requirements list is that the threads use 'standard' threading mechanisms for safety, such as mutex/semaphore, etc.., which should exist in the kernel as well.
This is inline with the Posix stuff, and rather than invent our 'own' new kind of data structure, I'd like to stick with known solutions that work and everyone for the most part understands.
Howeer, that requirement may be more detailed oriented than what you are looking for now.
Nate
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message





