Re: eiffel parser in SmartEiffel

On Jul 23, 12:05 am, llothar <llot...@[EMAIL PROTECTED]
> wrote:
> If you are really interested and willing to read source code and learn
> the smalleiffel source code, i'm maybe considering to publish my
> patched system.

> I'm still not sure about what you want to do but keep in mind that if
> you want to do multithreading you can't do it with SmartEiffel (and
> you never will be able to).

llothar,

I'm assuming this was addressed to me,but it's hard to tell with my
newsgroup reader.  I am busy evaluating SmartEiffel 2.3 at the moment
and I do not know the difference between your version and 2.3.  But
I would imagine that others would like to use your version since it
is proven.


As for multithreading, I have mentioned before my biases against it.
I say that because (a) I'm never sure if the development environment
will truly prevent deadlocks (b) even if the environment prevents it,
you may still have to deal with data deadlocks and (c) it is really
difficult to debug.  I have seen many large clients spend a lot
of time with issues (a) and (b) especially because of (c).

Having said this, we are faced with the problem that many processors
contain multiple cores and this is only expected to increase.  I just
read an article stating that processor developers think multi-core
processors are the way to increase the effective speed.  Given that,
I wonder if something like SmartEiffel's sequence library is the
way to go.  That is, you do not have to worry about thread safety (it
looks like).  You can provide a job with its own data and it
can run until completed or there is an error.

It seems that you would have to address the following issues:

(a) interprcess communication: so as the jobs could update their
status with the "main" program
(b) processor affinity: how to keep a job from being context
switched to a different core unless it was necessary

I'm sure that there are more, but these seem much more straightforward
than dealing with mutexes, locks, etc.

Lee