Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #3003 > unrolled thread

non-UI thread

Back to article view | Back to comp.programming

Contents

  non-UI thread bob <bob@coolfone.comze.com> - 2013-02-11 12:35 -0800
    Re: non-UI thread jt@toerring.de (Jens Thoms Toerring) - 2013-02-11 23:58 +0000
      Re: non-UI thread Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-11 17:44 -0800
    Re: non-UI thread "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2013-02-12 10:33 +0100

#3003 — non-UI thread

I've seen a number of systems where you can only modify the user interface on a certain thread - the UI thread.  Is this the case for just about all UI systems?

What are some problems that can happen if you change UI stuff on a non-UI thread?

[toc] | [next] | [standalone]

#3004

bob <bob@coolfone.comze.com> wrote:
> I've seen a number of systems where you can only modify the user interface
> on a certain thread - the UI thread. Is this the case for just about all UI
> systems?

I don't know what exactly you mean by an "Ui system" - perhaps it
is something like for example the (Unix) Xlib? There you could only
have one process/thread of a program sending requests to the X ser-
ver. If that's the case then, no, not all "UI systems" have that
limitation anymore. by invoking the function XInitThreads() you
can make the Xlib threadsafe and then send requests to the X ser-
ver concurrently from different threads. But keep in mind that not
all libraries based on the Xlib library does support this yet -
they also need to be threadsafe.

> What are some problems that can happen if you change UI stuff on a non-UI
> thread?

IN X it used to result in an X error when different threads sent
requests in an uncoordienated manner that the X server couldn't
deal with. Results could be anything from nothing noticable (ex-
cept some error messages going to stderr) to garbled graphics to
crashes. And, since this all depended on the exact timing, repro-
ducing the prolblem was basically impossible - not the kind of
error you'd like to have to debug;-)

                             Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#3005

On 2/11/13 3:58 PM, Jens Thoms Toerring wrote:
> bob <bob@coolfone.comze.com> wrote:
>> I've seen a number of systems where you can only modify the user interface
>> on a certain thread - the UI thread. Is this the case for just about all UI
>> systems?
>
> I don't know what exactly you mean by an "Ui system" - perhaps it
> is something like for example the (Unix) Xlib? There you could only
> have one process/thread of a program sending requests to the X ser-
> ver. If that's the case then, no, not all "UI systems" have that
> limitation anymore. by invoking the function XInitThreads() you
> can make the Xlib threadsafe and then send requests to the X ser-
> ver concurrently from different threads. But keep in mind that not
> all libraries based on the Xlib library does support this yet -
> they also need to be threadsafe.
>
>> What are some problems that can happen if you change UI stuff on a non-UI
>> thread?
>
> IN X it used to result in an X error when different threads sent
> requests in an uncoordienated manner that the X server couldn't
> deal with. Results could be anything from nothing noticable (ex-
> cept some error messages going to stderr) to garbled graphics to
> crashes. And, since this all depended on the exact timing, repro-
> ducing the prolblem was basically impossible - not the kind of
> error you'd like to have to debug;-)
>
>                               Regards, Jens
>
Another example is awt/Swing in Java land. They too have the requirement 
that all interaction with UI components happen on the Event Dispatch 
Thread (EDT).

This is simply one way to manage synchronization. If the entire UI 
system synchronized on a global lock for every call, then you wouldn't 
have to worry about which thread made the call.  But you *would* have to 
worry about deadlocks.  It isn't impossible to create a UI system which 
allows multiple threads, but generally it is easier to prove correct if 
only one thread does the UI processing.

This also actually makes it *easier* to create an app which is 
responsive, as long as you correctly offload non-UI work to other 
threads, and never block the UI processing thread.

[toc] | [prev] | [next] | [standalone]

#3006

On Mon, 11 Feb 2013 12:35:06 -0800 (PST), bob wrote:

> I've seen a number of systems where you can only modify the user interface
> on a certain thread - the UI thread.  Is this the case for just about all
> UI systems?

Not all. E.g. Win32 is multithreading.
 
> What are some problems that can happen if you change UI stuff on a non-UI thread?

Depends on what you mean.

If the framework is not multithreading then an attempt to do something on
the context of an alien thread will most likely crash the application.

If you mean potential problems which could arise when allowing multiple
threads, there are many. It complicates the design, it has issues with
generators, live-locks, race conditions etc.

Still, it is a shame that some if not most GUI frameworks are single
threading.

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web