On Monday, May 26, 2003, at 06:10 PM, Dave Whipp wrote:
Michael Lazzaro wrote:[snip]What I'm getting at is that all these concepts are much more related than they might at first seem, and that the differences between them are largely of "scope". If we have some form of coroutines, _and_ can run them in parallel, all the other constructs fall out of them fairly naturally. Even threads, for some pretty decent definition of "threads".
OK, Mike sayes "a single entity", and then "these concepts are much more related than...". Perhaps I'm being pedantic, but I relationships generally imply multiple entities. But perhaps he meant that things are so related that they become attributes of a single entity. I'd like to disagree: they may belong the a single domain, but to stick them in a single class would result in a bloated blob with a fat interface.
Sorry; I meant that the _current_ concepts are strongly related, but they _could_ be a single entity. Please forgive the somewhat spastic parts of the proposal -- like I said, it was less than an hour of thought, I certainly don't mean it to be a be-all-end-all. (In particular I'm aware I'm badly conflating the thread vs. scheduling issues.)
Most obvious is that the "Priority" attribute is a property of the relation between the execution context and its CPU resource manager (i.e its scheduler). In fact, I'd like to suggest the redical proposal that every shared lock should be able to have an associated priority for each blocked thread: and to enable this we'd want each lock to have an associated arbiter (the simplest of which would not have priorities).
Certainly, a separate and overridable thread-scheduler seems a necessity. I'd be annoyed if you couldn't swap out the scheduler.
What I really want, most of all, is a syntax for coroutines and a syntax for threads that is Damn Similar; similar enough so that one can be taught as merely a more encompassing extension of the other. Whether they should be absolutely identical is _very_ debatable, but I think it's worth some thought.
More in a sec...
MikeL
