Re: Multithreaded application freezing
- From: Göran Hasse <gorhas raditex nu>
- To: Paul Davis <paul linuxaudiosystems com>, Tristan Van Berkom <tristan upstairslabs com>
- Cc: ML-gtk <gtk-list gnome org>
- Subject: Re: Multithreaded application freezing
- Date: Thu, 05 Feb 2015 18:19:37 +0100
Hello,
Den 2015-02-05 16:13, Paul Davis skrev:
On Thu, Feb 5, 2015 at 7:40 AM, Tristan Van Berkom
<tristan upstairslabs com <mailto:tristan upstairslabs com>> wrote:
Everything Tristan said is precisely correct. But in addition ...
Exept that threads application ofthen hangs...
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.
Sorry... I have NOT done mutch MS-Window programming. This since I
for about 20 odd years ago noticed that sockets (file descriptors)
is the ONLY safe way to do communications by. (select, poll or kernel-queue etc).
And you should only have one place in your application for dispatching
events.
ALL other communications mechanism tend to lock upp your application in one
way or the other.
And since your communicate over a socket you can as well design
a good protocol to communicate by. And then it is easy to split the
application into serveral parts. You know like client/servers. And why
not many client-servers.
If you need a large memory segment you can use mmap() to have larger
memory area.
And you can study this in http://www.ibm.com/developerworks/aix/library/au-spunix_sharedmemory/
And you can easy pair this with sockets to communicate between processes.
http://youtu.be/m-rnf9a1sjs
Sorry for the exotic spoken language (Swedish).
The process in Unix *is* the multitasking abstraction.
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.
You must ask what event notification mechanisms you have
between threads!
Then read manual pages for kqueue() in BSD...
https://www.freebsd.org/cgi/man.cgi?query=kqueue
Were can i find something like this for threads?
And yes. My programs are a little bit more complicated - but they don't
hangs...
/gh
--
Göran Hasse
Raditex Control AB
OrgNr: 556611-8773
email: gorhas raditex nu
tel: 019-450105
mob: 070-5530148
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]