Re: Tasking and wxWidgets

["Lucretia" <lucretia9@lycos.co.uk>]

> > Hmm, but if each wxAda type had it's own mutex, surely you'd only end
> > up locking that particular object at any one time?
>
> Depends on what is the object here, and what is allowed to do with a mutex
> taken. If there is a possibility to perform blocking actions within other
> actions, then be ready for hell. One way to get out of this is to remove
> mutexes from objects and pass them as parameters or discriminants. Another
> is to use monitor tasks.

The object could be any of the wx objects, a wxFrame, wxButton,
wxToolBar, wxStatusBar, etc.

> > It's a possibility if somebody wanted to create an image manipulation
> > program with wxAda?!
>
> Do you ask me? (:-)) Look at absolutely useless Window's SetPixel. Then
> you'll need double buffering and all that stuff.

No! I mean't it is possible that somebody would want to.

> >> often use a specialized "mutex" which allows parallel read access if there
> >> is no any write access. It would be nice to use Ada's protected objects
> >> here, because they basically have this functionality, but unfortunately 1)
> >> the thing is in C++, 2) Ada's protected objects aren't OO composable, they
> >> are not tagged.
> >
> > Exactly, and getting multiple objects using protected objects is
> > impossible, unfortunately.
>
> Hmm, do you mean multiple protected actions here?

No! I mean you cannot create derivable types from protected types. The
wxAda hierarchy matches that of the C++ wxWidgets hierarchy. wxObject
(wx.Base.Object.Object_Type) is the base type and everything derives
from there. wxEvtHandler (wx.Base.Event_Handler.Event_Handler_Type)
derives from wxObject. wxWindow derives from wxEvtHandler. wxControl
derives from wxWindow. etc.

So, how do you make this thread safe? All controls are windows and all
events go through the event handler classes. In the wxWidgets library
there is minimal thread safe code in the event handling code, but do I
want to make a completely thread safe library or leave it up to the
application developer?

> >> And more than two mutexes is a problem. You should try to make the API
> >> composable without or minimal deadlock danger. For example, Windows GUI API
> >
> > I'm not sure what you mean about "composable without or minimal
> > deadlock danger"
>
> From the messages loop [in a deeply nested callback subprogram] you spin
> for a mutex held by another thread that does SetWindowText to the window.
> Here you are.

Eh?

Thanks,
Luke.