You can still deadlock with two different processes (getting your protocol marshalling into a state where both processes are waiting for an RPC reply from the other), and we've seen it with DBus interfaces before.
Really, the ability to not hang relies on careful engineering and understanding the tradeoffs of your system.
Having two socket connections to the X server isn't magical, and if one processes hangs, then one window of your two-window application is broken. To a typical user, that's just as good as the entire thing hanging.
Having two socket connections to the X server isn't magical, and if one processes hangs, then one window of your two-window application is broken. To a typical user, that's just as good as the entire thing hanging.
And when the window that's still alive tries to make RPC to the hung processes, well, now your entire application is toast.
On Thu, Feb 5, 2015 at 9:28 AM, Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote:
On Thu, Feb 5, 2015 at 12:19 PM, Göran Hasse <gorhas@xxxxxxxxxx> wrote:
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).this is false.And you should only have one place in your application for dispatching
events.this is false, although in the limited sense that a particular event loop should only run in a single thread, it is correct.
ALL other communications mechanism tend to lock upp your application in one
way or the other.this is false.
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.it might be easier for some purposes, but it is vastly more complex for others. and in your case, you recommended one process per window, which is absurd.
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/i've been writing Unix applications for nearly 30 years. I don't need to read AIX documentation, thanks.
The process in Unix *is* the multitasking abstraction.process-level parallelism is certainly more common in the unix world than on other platforms. but there is no reason to avoid threads when they are appropriate. and there is certainly no reason to use one process per window.
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?threads can use all the same mechanisms as processes, but don't have to use OS provided APIs to share address spaces. that's really the only difference.
And yes. My programs are a little bit more complicated - but they don't
hangs...my program typically runs between 12 and 26 threads inside a single process. It has only a single thread that makes any GUI function calls (other than g_idle_add() or its equivalent). it doesn't hang.but more generally, MOST applications don't need multiple threads or multiple processes, even when they have multiple windows. to suggest that you should plan on 1 process per window is crazy.
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list
--
Jasper
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
