I want to say that I think the Thread class approach might be less painfull but equally effective. I assume the Thread class would have to do all the scheduling and the preemption. Am I right?
Also about making unicon work with jcont, it sounds easy but it might too good to be true. Not knowing about jcont, what are the differences other than the apparent java involvement?
beers,
Kosta Tachtevrenidis
Taybin Rutkin wrote:
Yes, this is how Python does it. It's just another library that wraps the threads into a Thread class that implements Runnable. I think this would be a good way to go about it.
Taybin
-----Original Message----- From: Steve Wampler <[EMAIL PROTECTED]> Sent: Jan 21, 2004 3:55 PM To: Michael Meehan <[EMAIL PROTECTED]> Cc: Unicon <[EMAIL PROTECTED]> Subject: Re: [Unicon-group] Concurrency Features for Unicon
On Wed, 2004-01-21 at 12:45, Michael Meehan wrote:
Hello,
I have been thinking about adding Concurrency features to Unicon. Below
are some ramblings on the subject.
Cool!! This is a *neat* idea!
In order to be able to generate and utilize these new op-code(s) two
things must be done
(1) the i-code interpreter must be modified to recognize and implement
the new op-code(s)
(2) the icon translator must be modified to recognize new syntax for
concurrency features and must be made to generate the new op-code(s) as
appropriate. It is the icon compiler that must be modified in that we
will be generating new instructions for the i-code machine. This cannot
be done at the Unicon compiler level as it emits icon code not i-code
instructions.
Hmmm, not that I've thought about this much, but would you really need to modify *any* Unicon syntax? Wouldn't a new class (implemented in the underlying C/C++, perhaps) called, oh, say: Thread() be sufficient?
And, wandering ever farther afield... Couldn't the implementation of a co-expression be adjusted to assume the same role that a 'Runnable' in Java does? Normal (i.e. existing) co-expression behavior would be unchanged, but something like:
t := Thread(create <EXPRESSION>)
would attach the co-expression to Thread t. Then, ala Java (just for illustrative purposes):
t.start()
would initiate the thread and activate the co-expression. Heck, once the thread is running, the co-expression could be activated in the 'normal' fashion within the execution of the start() method, he claims. So *any* co-expression could be run concurrently simply by attaching it to an instance of the Thread class.
I'm not even sure that the icode would have to modified in this scheme, but have probably wrong on that score. If I'm right, though, then *all* the concurrency features would be contained solely within the implementation of the Thread class and the rtt-based runtime code.
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
