Issue status update for
http://smalltalk.gnu.org/project/issue/98
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/98
Project: GNU Smalltalk
Version: <none>
Component: VM
Category: feature requests
Priority: normal
Assigned to: Unassigned
Reported by: sblinn
Updated by: elmex
Status: active
Here are some of my mostly random thoughts about this:
Yes, this seems to be highly non-trivial to me.
But in times of multi-core CPUs popping up everywhere
(even under my desk), it would certainly make GNU
smalltalk even more interesting.
But I guess there will be big issues with the GC
and the I/O subsystem.
I also wonder how the API would look like on the
smalltalk side. Can I specify which thread is a
"real" thread? What kind of locking can I use?
Will the VM crash on me when I write to an object
at the same time? Are there alternatives?
My opinion is that locking and synchronizing should
be up to the Programmer. Thread programming and
synchronization is a very complicated thing and there
is afaik no easy way out. Let the programmer decide
wheter he needs real threads and when he needs
synchronization.
I just wanted to say that IF I get real threads somehow
in smalltalk, I want to control which [] fork results
in a real and which in a pseudo-thread. And that
if I mutate an object in two "real" threads at the same
time (without locking) I deserve a segfault and core dump
or corrupted data.
_______________________________________________
help-smalltalk mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
