From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1742659b6aa943fb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!g47g2000cwa.googlegroups.com!not-for-mail From: "Lucretia" Newsgroups: comp.lang.ada Subject: Re: Tasking and wxWidgets Date: 28 Nov 2005 02:48:26 -0800 Organization: http://groups.google.com Message-ID: <1133174906.814986.234190@g47g2000cwa.googlegroups.com> References: <1132913111.023558.255590@g14g2000cwa.googlegroups.com> <12gydxpbzl6wr$.u5gqms25vc8n.dlg@40tude.net> <1133019723.900827.144340@o13g2000cwo.googlegroups.com> <1klj2l99vjffc.20si9rutfd0p.dlg@40tude.net> NNTP-Posting-Host: 194.74.199.42 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1133174911 8688 127.0.0.1 (28 Nov 2005 10:48:31 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 28 Nov 2005 10:48:31 +0000 (UTC) In-Reply-To: <1klj2l99vjffc.20si9rutfd0p.dlg@40tude.net> User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0),gzip(gfe),gzip(gfe) X-HTTP-Via: 1.0 Symantec_Web_Security (3.0.1.74), 1.0 C2100-0050414028 (NetCache NetApp/5.5R5) Complaints-To: groups-abuse@google.com Injection-Info: g47g2000cwa.googlegroups.com; posting-host=194.74.199.42; posting-account=G-J9fgwAAADgpzBiEyy5tO4f8MX5fbpw Xref: g2news1.google.com comp.lang.ada:6655 Date: 2005-11-28T02:48:26-08:00 List-Id: > > 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.