Re: Multithreaded application freezing

[Göran Hasse <gorhas raditex nu>]

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