Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail From: jt@toerring.de (Jens Thoms Toerring) Newsgroups: comp.programming Subject: Re: non-UI thread Date: 11 Feb 2013 23:58:29 GMT Organization: Freie Universitaet Berlin Lines: 30 Message-ID: References: X-Trace: news.uni-berlin.de PWMpWOGl7J40tyQ+p+3zqwZgDj7KTv4FsRskidUbYLMOS/g0VfipBawuZUB3nq X-Orig-Path: not-for-mail User-Agent: tin/1.9.3-20080506 ("Dalintober") (UNIX) (Linux/2.6.30-1-amd64 (x86_64)) Xref: csiph.com comp.programming:3004 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? 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