Thread-safe SmallEiffel beta-4 based on version 0.74
Miguel Oliveira e Silva
since it's based on SmallEiffel -0.74 version).
The most important differences (besides some bug corrections) are
the re-implementation of once routines, a first attempt to wrap
the X11 (thread-safe) graphic library to Eiffel, and some new
classes in the thread basic library.
- Once routines.
ETL3 once routines proposals are now implemented with some syntactical
changes:
1- The onceness scope delimiter was changed from '(' ... ')' to
'{' ... '}', to avoid an ambiguous grammar. For example:
a_once_proc
once ("OBJECT")
...
end;
is almost equal to the very different code:
a_once_proc
once
("OBJECT").feature_call ...
end;
Since the delimiters '{''}' are used in other Eiffel constructs
to express their applicability/scopeness (feature export status,
for example), it seemed a better consistent alternative.
2- Instead of allowing the expression of a unique key (as proposed in
ETL3), a list of non-conflicting keys can be expressed.
There are four default key strings: "thread", "process", "object" and
"class"; from which exist four (self-explaining) possible combinations:
once {"thread","object"}
once {"thread","class"}
once {"process","object"}
once {"process","class"}
It is also possible to use other arbitrary keys refreshable using the
ANY's feature 'onces' (of type ONCE_MANAGER), as defined in ETL3.
The ('C') code generated on once routines is now optimized (no need
for traversing binary trees or hash tables). The HISTORY file logs
most of the changes made.
- X11 library
A first attempt to wrap the basic X11 graphical library is made (for
the moment is located in the example's lib directory).
Knowledge of the X11 library is highly recommended on its usage (although
its use is simpler than in 'C' since many boring bookkeeping code is no
longer necessary). There are two examples using this library: 'x11' and
'particles_x11' (in this last one there is one thread for each particle,
and their trajectory takes into consideration all the other particles).
- New thread library basic classes
'once_manager.e': necessary for once routines with arbitrary keys
'thread_attribute.e': allows the (very useful) definition of thread-scope
attributes (each thread works on a separated area).
Thread-attributes are another useful exception which does not
compromise inter-object concurrency (I'm thinking of proposing
a similar language construct for the OO concurrent language
I've been working on).
As with all the past versions, no attempt was made to port this
package for non-UNIX systems.
The new release can be found at:
http://www.ieeta.pt/~mos/thread-safe-se_beta4.tgz
http://www.ieeta.pt/~mos/se-0.74.tgz
-miguel
--
Miguel Oliveira e Silva email: m...@det.ua.pt
Dep. de Electrónica e Telecomunicações / IEETA
Universidade de Aveiro - PORTUGAL
phone: +351 234 370375 fax: +351 234 370545
www: http://www.ieeta.pt/~mos
Eric Bezault
> - Once routines.
>
> ETL3 once routines proposals are now implemented with some syntactical
> changes:
>
> 1- The onceness scope delimiter was changed from '(' ... ')' to
> '{' ... '}', to avoid an ambiguous grammar. For example:
>
> a_once_proc
> once ("OBJECT")
> ...
> end;
>
> is almost equal to the very different code:
>
> a_once_proc
> once
> ("OBJECT").feature_call ...
> end;
How is it different from the following syntax for
debug instrructions:
debug ("debug_key")
...
end
and:
debug
("debug_key").feature_call ...
end
? I don't think that the grammar is ambiguous, it just
requires the parser to read the token after the closing
parenthesis in order to decide whether it just read a
parenthesized string expression or a single-element
debug key set or onceness scope.
--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com
Miguel Oliveira e Silva
It isn't. The grammar problem is exactly the same.
> ? I don't think that the grammar is ambiguous, it just
> requires the parser to read the token after the closing
> parenthesis in order to decide whether it just read a
> parenthesized string expression or a single-element
> debug key set or onceness scope.
True.
The main problem to me, is that from a slight change in
the code text, results in a big semantic change in the
program. This is not a desirable language property.
The change to the '{''}' delimiters (in both language
constructs) would prevent this problem.
(This is not a critical problem. The delimiters are
easily changed in the SE's source code in the class
'eiffel_parser.e', feature: 'a_once_key_list'.)
For the record: if separators were not optional, and the
debug/once instructions used the proposed delimiter,
a context free grammar (which is much more efficient)
could be generated for Eiffel with yacc/bison or antlr
parser generators (I have one for antlr).
(Of course today this point is no longer as important as it
was in the past, since most of the compiling time in a
language like Eiffel is spent in the code analysis/generation,
and not in the scanning/parsing.)
> --
> Eric Bezault
> mailto:er...@gobosoft.com
> http://www.gobosoft.com
-miguel