Re: OO2C -> Debian?

[Mike Griebling <grieblm@trt.allied.com>]

> In my opinion this means for VO: All graphical interaction must be
> handled by one single thread. Use and access of models by different
> threads must be protected my semaphores by the programmer itself. Is
> this true? Are there alernatives, options I missed? Is the current

Well, at least the X-windows interface must be protected if not already
threadable.

> status of VO useable, given the restrictions above? Should it be
> redesigned? Mike: You as BeBoxer, how does the BeBox graphic engine
> handles this? I know, the Bebox uses C++. Using methods as in VO will

On the BeOS, the windowing system is thread-safe so method-like calls
via C++ (or Oberon-2 if I ever get time to work on the interface) should
be safe.  In the BeOS, at the lowest level, graphic calls are always
locked via a semaphore to prevent conflicting access to the display.
At the C++ level, usually you don't have to worry about locking the
display -- it is done automatically whenever you invoke the Draw method.
The only time you have to explicitly lock the display is if you are
doing low-level display operations outside the Draw method.

> result in the same problems. Do they recuce themselfs to messages, too?

No, messages are not used for drawing.  That would be too slow for a
multi-media OS.  Messages are used for the user interface though but
that's pretty standard.

> The oo2c library uses classs and methods, too. Are thus the problems
> mapable? And as a conclusion: Should the library at all handle thread

I'm not sure what you mean here.  If you mean is it possible to do the
locking/unlocking in a base class, then I think so.

> safety on this level, or should it leave the problem completely to the
> user, which then must allways protect acces to objects itself?

This is probably dependent on performance issues.  Locking everything
will involve some overhead which may not be desirable.  However, I do
think that leaving the locking up to the user is playing with fire.  I
guess whenever possible and the performance hit is negligible, the locking
should be automatic -- otherwise, I would prefer the user to lock the
resource.  With OO2C, there aren't many performance issues.  The main
ones might be memory management locking which should be automatic in
keeping with the spirit of Oberon-2.  I don't believe there would be
any performance hits in automatically locking files and stuff like
timers.

> > access is another area where the allocator has to be "thread-safe"
> > to prevent multiple threads getting the same block of memory and
> > other nasties.
> 
> This should be a problem of the gc implementation. If the gc handles
> this, VO should not need to worry about that.

True.  Of course, I have been trying to get our own memory allocator that
would be Oberon-2 native.  The main reason is it would be faster than
Boehm's collector since it could take advantage of Oberon's strict typing.
As well, I've been having problems getting Boehm's collector to multi-thread
under the BeOS -- mainly because I don't understand his collector very
well.  In the time it would take me to understand it, I can probably
create a better one in Oberon-2.

Michael G.