Xref: utzoo comp.windows.x:32903 comp.windows.x.motif:1951
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!samsung!uunet!orca!mesa!rthomson
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Newsgroups: comp.windows.x,comp.windows.x.motif
Subject: Re: Concurrency in a widget tree or window tree?
Message-ID: <1991Feb18.233514.23799@dsd.es.com>
Date: 18 Feb 91 23:35:14 GMT
References: <1504@ipsi.UUCP>
Sender: usenet@dsd.es.com
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Lines: 54
Nntp-Posting-Host: 130.187.85.21

In article <1504@ipsi.UUCP>
	zhao@ipsi.UUCP (Jian Zhao) writes:
>In a widget tree, some subtrees belong to different clients, but their
>behaviors are the same as in one client.

Since widgets live inside the client process, this will be difficult
without a complete rewrite of Xt.

>If this is difficult on the widget level, can I do something similar on
>the window level (i.e. in a window tree, some subtrees are connected with
>different clients)?

Windows live in the server (but are only part of the state of a
widget) and any client program that knows the window ID of a window
(and has a connection to the display on which the window was created)
can do output to the window.

However, there are some restrictions on selecting input on a window
from multiple clients.  Basically, selecting for a button press on a
window is a one-client-only kind of operation, while selecting for an
expose event on a window can be done by multiple clients.

XID's (and thus window IDs) are constructed from two parts: the client
part and the resource part.  The client part is derived from the
process id of the client, I believe.  My impression is that the
process creating the window in the server must still be running in
order for that window to be displayed (i.e. if you kill the client,
its resources are freed in the server, which includes windows).

I'd be interested in hearing anything more you find out about the
possibilities.  Writing really big software programs that interact
with the user through graphical interfaces can be problem.

The solution to the "one, big executable" problem is to split the
program into multiple modules, each executing in a single process
(also prevents one from having to link with a huge amount of other
stuff to get something that runs).  However, once the process is split
into multiple processes, you have a problem with the basic:

    while (1)
	GetEvent(), ProcessEvent();

model of input processing.  You either have a central process that
distributes the input across multiple compute processes, or a bunch of
processes all attempting to manage the same input, possibly
communicating back and forth to each other to establish some kind of
control protocol (i.e. who has the user's focus?).

						-- Rich
-- 
  ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon
	    Disclaimer: I speak for myself, except as noted.
UUCP: ...!uunet!dsd.es.com!rthomson		Rich Thomson
ARPA: rthomson@dsd.es.com			PEXt Programmer