Re: Tasking and wxWidgets

On 28 Nov 2005 02:48:26 -0800, Lucretia wrote:

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

This is rather a "visual" hierarchy, i.e. things are arranged on the
screen. But how does it work. Does wxButton send a message to wxFrame, or
wxFrame queries wxButton for its state, or maybe wxButton has On_Click
abstract method to override etc.

> No! I mean you cannot create derivable types from protected types.

Yes. However you can:

type Protected_Action is abstract tagged ...
procedure Perform (What : in out Protected_Action) is abstract;

protected type Subject is
entry Request (What : in out Protected_Action'Class);
...

protected body Subject is
entry Request (What : in out Protected_Action'Class) ... is
begin
Perform (What); -- Dispatches
end;

Yet, it would be a very bad idea to perform rendering from a protected
action.

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

Does wxEvtHandler encapsulate a thread?

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

I will be difficult if possible in thin bindings if the library design
wasn't thread safe.

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

The messages loop waits for the mutex. The thread holding the mutex waits
for SendMessage to return the result. Deadlock.

Things like this happen. [ The design problem is that rendering actions
(like SetWindowText) and semantic actions (potentially lengthy and
serialized) are served by the same thread. ]

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Quantcast