Re: OO2C -> Debian?

[Tim Teulings <tim@edge.ping.de>]

Hallo!

> Generally, to be threadsafe, all shared resources such a hard disk
> or a display (for VO) must be protected by semaphores (or some other
> mechanism) so that threads won't get conflicting access to that
> resource.  If VO has one thread managing the display which gets
> queued messages from all the other threads writing to the display,
> that would be one way to make VO thread-safe.  As I mentioned, memory

This will be a huge problem then. The interface to the drawing
mechanism is (per design) rather huge. Every method of
VODisplay.DrawInfo thus had to be protected, also drawing as a result
from the main event loop (Refreshing, resizing and - important - user
feetback). But this is not all. Models do directly communicate with
their viewer. Changing a models from within any thread directly calls
methods of one or more objects. There is a huge amount of methodscalls
that thus have to be protected. This is a priciple design weekness I
got aware of in the near past. While I hate the design of e.g the Win32
API it reduces the probelm beacuse of it use of messages (insead of
directly maped methods) going ttrough a message broker. By protected
and serializing the message broker you get thread safety. The directly
maped methods of Oberon-2 used by VO for direct object interaction in
most cases (user event handling and the object interaction mechanism
use single message reciever methods because they are more flexible)
makes this much more difficult.

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
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
result in the same problems. Do they recuce themselfs to messages, too?

The oo2c library uses classs and methods, too. Are thus the problems
mapable? And as a conclusion: Should the library at all handle thread
safety on this level, or should it leave the problem completely to the
user, which then must allways protect acces to objects itself?

> 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.

-- 
Gru...
       Tim.