Re: Multithreaded application freezing





On Thu, Feb 5, 2015 at 7:40 AM, Tristan Van Berkom <tristan upstairslabs com> wrote:

Everything Tristan said is precisely correct. But in addition ...

 

You seem to be going off on a tangent here, your claim was that:

 "every window in an application should be in a separate process"

I have a hunch about where you might have gotten this idea from.

On Windows, window handles must have their events serviced by the thread that created them. This works because Microsoft chose to put implicit locking throughout their GUI code so that it is inherently multithread safe. This is convenient if you write applications that uses many threads that all call GUI functions. But it has overhead for applications that are either fully single-threaded or only make GUI function calls from one thread.

X Window evolved in a different direction: it is NOT multithread safe, so applications which want to use more than one thread to make calls into Xlib must use their own explicit locking. This is inconvenient if you come from a Microsoft-influenced development background, but has low overheaded for the many, many single threaded applications. It has also influenced the design of many other toolkits that originated at least in part on X Window and has pushed their design toward the "use a single thread to make GUI function calls" model. This leads to much cleaner application design in almost all cases.

I don't know what your development background is, but it is easy to imagine someone who started on Windows imagining that it makes sense to equate threads and processes and thus conclude that each window should be serviced by its own process.

Unfortunately, this view is wrong.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]