I thought I'd replied earlier, but it doesn't seem to have made
it all the way to this list....
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 - *very* cool...
> 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, I haven't thought this through, so please take it with a grain
(or more) of salt, but...
Is there really any need to modify the Unicon syntax at all? (And
I'm not sure that the icode would have to be modified at all - just
the runtime [that may be enough in itself!].
For example, suppose all the threading support could be encapsulated
in a single class called, say, Thread(). Then a co-expression could
be attached to an instance of Thread(), perhaps by the constructor
as in:
thread := Thread(create <EXPRESSION>)
and the execution of the thread initiated with, say, a method call
as in:
thread.activate()
the activate method could context switch to the new thread and then
activate the co-expression in the 'normal' way. So, no new Unicon
syntax is needed for *using* a Thread()... (Relating all of this
to Java, Thread() akin to new thread() and co-expression are
analogous to Runnables.
Now, the only reason that icode would be required would be if the
Thread() class were to be implemented in Unicon [and you'd need
need the Unicon support there, but perhaps even then only through
function calls]. However, must Thread() be implemented in Unicon?
After all Unicon is a VHPL that provides a number of other features
(e.g. arbitrary-sized integers) without providing language level
access to the implementation details. So, could the support for
the Thread() class be handled in the same way - implemented solely
in the runtime library? Even if it's too hard to provide a class
implemented in something other than Unicon itself, I'd still claim
that all the support for concurrent threading could be implemented
via runtime functions and so avoid the need to change either Unicon
or the icode.
I think I'd tend to favor any implementation that provides
a high-level abstraction of concurrent execution that 'fits' with
the VHPL model of Unicon.
Of course, the people willing and able to do a *real* implementation
carry a Great Deal of Influence over the design...
--
Steve Wampler <[EMAIL PROTECTED]>
-------------------------------------------------------
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
