From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Tasking and wxWidgets
Date: Mon, 28 Nov 2005 15:41:49 +0100
Date: 2005-11-28T15:41:49+01:00 [thread overview]
Message-ID: <kmfkkbn289wf$.zdg0zpl7rm6w$.dlg@40tude.net> (raw)
In-Reply-To: 1133174906.814986.234190@g47g2000cwa.googlegroups.com
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
next prev parent reply other threads:[~2005-11-28 14:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-25 10:05 Tasking and wxWidgets Lucretia
2005-11-25 10:53 ` Martin Dowie
2005-11-26 17:32 ` Lucretia
2005-11-26 18:23 ` Martin Dowie
2005-11-29 3:07 ` Randy Brukardt
2005-11-29 9:13 ` Martin Dowie
2005-11-29 21:46 ` Randy Brukardt
2005-11-29 22:46 ` Martin Dowie
2005-11-25 11:37 ` Dmitry A. Kazakov
2005-11-26 17:26 ` Lucretia
2005-11-27 11:15 ` Dmitry A. Kazakov
2005-11-28 10:48 ` Lucretia
2005-11-28 14:41 ` Dmitry A. Kazakov [this message]
2005-11-26 17:26 ` Lucretia
2005-11-26 17:28 ` Lucretia
2005-11-26 17:34 ` Lucretia
2005-11-26 7:46 ` Simon Wright
2005-11-28 10:37 ` Lucretia
2005-11-29 21:38 ` Simon Wright
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox