Re: User interface thread

Eugene <[email protected]> Sun, 13 Nov 2005 20:47:09 +0300
Newsgroups gmane.comp.games.mud.client.lyntin
Message-ID <[email protected]>
On Sun, 13 Nov 2005 10:48:53 -0600 (CST)
  will guaraldi <[email protected]> wrote:
>On Sun, 13 Nov 2005, Eugene wrote:
>>
>> Shutting the lyntin down is a bit messy and has some 
>>races, so I 
>> consider clarifying threading issues a bit. The code in 
>>question is 
>> unnecessarily hairy by now.
>
>In regards to the first sentence, I haven't seen any 
>issues with the existing UIs.  So while I acknowledge 
>there could be race conditions involved with exiting, I 
>haven't seen any evidence of them.

There are some. The races don't appear always, because 
they are, well, races. I get one unhandled exception for 
every ~20 shutdowns. It appears only when shutting down, 
so it's efficiently harmless, but anyway there is no good 
in that.

>I think if I were to re-re-rewrite Lyntin, I'd do it with 
>Twisted and not use threads at all.

I'd call it a bit more than "clarifying". Anyway, it is 
kind of task for 5.0 or even 6.0. But anyway you cannot 
rid out of threads even with the Twisted - there is a good 
practice
in the Twisted to have a pool of threads for some strongly 
isolated tasks.

>> I guess, if any UI module can tell it wants the main 
>>thread, and the 
>> engine has no problems with it, then we could just as 
>>well run any UI in 
>> the main thread. I hardly can imagine a toolkit that 
>>objects against 
>> running in the main thread.
>
>Well, if there is an answer to that question, it'd 
>hopefully be in the mailing list archives.  I'm pretty 
>sure I didn't architect it that way arbitrarily, but I 
>don't remember more than that.

Could 'legacy design' be an answer? First, the engine was 
implemented in the main thread an the UI in the another 
thread, and then some toolkits wanting the main thread 
appear, and then the want_main_thread() method was 
introduced.

Anyway, it looks like the engine is pretty ok about 
running not in the main thread (because it does so every 
time the UI tells it to do so); and I don't know of any UI 
toolkit that requires _not_ main thread. So, if we run UI 
always in the main thread, and the engine in the child 
thread, all should be fine - where am I wrong?

--
Eugene
---
Professional hosting for everyone - http://www.host.ru


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php