On Fri, 14 Sep 2001, Rob Withers wrote:

> I like this direction of discussion.  Let us consider making the
> Scheduler preemptive.  It would not be that difficult to introduce

Isn't it preemptive already?

Better idea... Support both preemptible and non-preemptible processes. For
example, we can have TCL-like event loops by having multiple
non-preemptible threads each of which blocks on doing IO. Each
event-waiter is just a seperate thread. This is clean.

> Isn't the real question whether we want to move squeak into a
> multi-threaded/-processing/-tasking environment, with all of the
> deadlock and starvation issues?  The current mechanism of polling

No way! Concurrency is an incredible bitch.  Yes, its very useful many
times, but its also a huge source of bugs, problems, and locking issues.

My multiuser multi-socket chat program is already an example of that.  I
needed a 'secure' sockets. Where, I disable reading in data if the
outgoing queue gets over one threshold. If it exceeds a second threshold,
I drop outgoing lines to that socket. I also catch excessively long lines.

For obvious reasons, I do not want to have the reader process busywait on
the length of hte queue and skip reading the network if the outgoing queue
is too long.

You try to construct the locking strategy for this; its ugly and annoying.
It took me 2-3 hours to get it... But I think I have no mistakes or race
conditions.

I did this because I wanted to keep all ofthe concurency out of the rest
of my code. (All of those rpocesses feed into a single worker process)
After doing the implementation, and being reminded why multithreading
stinks, I am very glad that I did push it all elsewhere.

Also, see:
	http://www.softpanorama.org/People/Ousterhout/Threads/

Which I fully agree with.

I'm not saying that multithreading is useless or unimportant. There are
many times where you do want it. But normally, it introduces a lot of
complexity a lot of the time, without too much practical gain.

>
> My current belief, on these topics, are that a preemptive scheduler,
> combined with coroutines in the VM message sending stack, would open
> the door for some incredible avenues into multimedia.  We ought to
> have a safe, preemptive, reentrant environment.  Is this a reasonable
> goal?  If I only had the time and expertise in these areas, I would
> try to do it myself...but I don't ;-)
>

Please no!

Go read the above presentation..


Scott