x interprocess communication
Dr d b karron
I may even have to write it;
come to think of it, I did write one using shared memory and user signals.
Code available on request. It is right now buried in the SGI developer
toolbox.
What I want to know is: a better way ? What is wrong with signals ? Works
ok, but I guess I want to fix it even if it aint broke;
how do other people break these things ?
My goal is to have two windows with two window cursors; if the mouse cursor
is in one window,
the window cursor in the other window is slaved to the main window
through my rinky dinky mathematical algorithmic gizmo wizzardwiry.
Move the mouse in one window, see the results in the other window.
Slide the mouse over to the other window, see the results in the window you
slid over from.
The idea is you are looking at the same scene drawn by space and the other
drawn by, say, ahem, Fourier space or wavelet.
Wiggle in Cartesian space, see your results in Fourier space.
Ziggle in Fourier space, see your wiggle in Cartesian space.
Intuitive as hell, IMHO; Should be simple in Xlib;
I can send events over to another window XID I get from a shared memory
region, or from an invisible parent window, or some
way to share data between independent threads.
Instead of writing a big incomprehensible paper, I want to make a simple
demo you can wiggle your mouse in and see how it works without a lot of
symbology and verbiage.
dr. k
"Chuck Dillon" <cdi...@nimblegen.com> wrote in message
news:3D49A3D5...@nimblegen.com...
> Dr d b karron wrote:
> >
> > What is the best way for two subwindows to communicate quickly and
> > efficiently ?
> >
> > I am thinking of multiple windows/frames for graphics windows that will
move
> > and rezize within each other;
> > each is its own main thread.
> >
> > I wrote some codet to demonstrate x interprocess communication using
shared
> > memory and kill(USR{1,2} interrupts;
> > I can post if if anyone wants to see how I started to do this.
> >
> > What is the modern(istic) way to do this ?
>
> Windows don't communicate with each other??? The only X IPC is via
XEvents. X has no notion of shared memory, except for the XSHM
> extension. Signals are not known to X either. Please clarify what you
are doing/trying to do.
>
> >
> > Sometimes I feel X is like Flintstone technology (cars you push/break)
with
> > your feet, no engine, dinosaurs do everything for you)
>
> Perhaps you are working at the wrong level. You probably need to work
with a toolkit(s) that provides the higher level
> functionality you need.
>
> -- ced
>
>
> --
> Chuck Dillon
> Senior Software Engineer
> NimbleGen Systems Inc.
The Ghost In The Machine
<ca...@thorn.net>
wrote
on Thu, 01 Aug 2002 22:01:05 GMT
<Bci29.154$tI4....@monger.newsread.com>:
Ah, this is interesting. However, there's only one global pointer in X.
This global pointer can enter and exit windows (Enter event, Leave event)
and be warped (XWarpPointer()); each window can change the icon of the
global pointer within itself as well (and that icon can get as fancy as
you want, within reason). It can also be grabbed (not something you'll
need for this problem, most likely). However, it cannot be replicated.
(There's also a keyboard focus, which is separate and probably not
an issue here. However, a graphics app might want to implement
the arrow keys in certain circumstances, to move the cursor within
a window.)
Contrast this with the rectangular cursor present in many terminal
emulators, editors, and word processors, which is a graphical artifact.
Blinking is done by redrawing the artifact.
The app controlling the window can of course draw what it wants. Most
likely you'll have to draw a cursor in both windows which will follow
the X pointer using MotionNotify events (in that case you have the option
of setting the mouse pointer to be invisible with an appropriate call
to XDefineCursor(), after creating the cursor). Or you can try to track
which window has the mouse pointer and draw something in each window
that doesn't have the mouse pointer; since each window is driven by
its own process or thread, this might be a minor problem.
Since you're crossposting to an OpenGL group, one might also use
OpenGL instructions to draw something. For example, I could easily
see an application "viewing into" a 3-D representation; something in
the window could look a bit like a flashlight with a cross on it. As
the user moves the mouse in 2-D space, the app computes the location
in 3-D space (where it hits a virtual wall, panel, or geometry) and
generates OpenGL instructions, updating the window.
You can also send client events (which are defined by the application),
or synthesize pointer events (which is probably not the best way to
go in your case as it seems that your cursors will move differently
in different windows; window A is not going to know how the cursor
moves in window B). Because of the way you've specified the problem,
the window will have to send multiple events (to all the other
windows), a minor fanout problem. This strongly suggests a central
dispatcher (a Controller, if you will).
It depends on how your app is structured, admittedly. How do the threads
know that they're supposed to communicate with each other?
--
#191, ewi...@earthlink.net
It's still legal to go .sigless.
Chuck Dillon
>
> yep, a tool kit that does what I want.
> I may even have to write it;
> come to think of it, I did write one using shared memory and user signals.
> Code available on request. It is right now buried in the SGI developer
> toolbox.
>
> What I want to know is: a better way ? What is wrong with signals ? Works
> ok, but I guess I want to fix it even if it aint broke;
> how do other people break these things ?
>
> My goal is to have two windows with two window cursors; if the mouse cursor
> is in one window,
> the window cursor in the other window is slaved to the main window
> through my rinky dinky mathematical algorithmic gizmo wizzardwiry.
If what you want is to implement the communications in the X layer so that your two windows can be running on different machines.
Then what you have to choose from is XEvents (e.g. the client event) or a combination of window properties and event handling. If
the information to be passed will fit in 20 bytes you can simple send ClientMessages between the windows. The respective
applications must select to receive and process those events.
If more information is involved your two apps could use properties. In this scenerio the property(ies) are basically mailboxes.
When app A sets a property app gets a propertyNotify event and then fetches the data from the server. The selection mechanism sits
on top of this kind of mechanism.
However, you refer to using shared memory and signals and threads which indicates that the apps are on one machine or may actually
be one process with multiple threads. In either case you have better options in the OS layer. If it's one process with multiple
threads they share an address space and so can interact using a common memory area and synchronization mechanisms like mutexes, and
conditional waits. See the pthreads doc.
If you are talking about two processes on the same machine you have your OS's IPC mechanisms to chose from. Apparently that's IRIX
so you can choose from pipes, sockets, signals, semaphores, message queues. As far as signals are concerned, if you go that route I
suggest you look at using POSIX RT signals which are queued and can carry a small payload of data between your apps. A socket based
solution would be network ready and so could scale to the case where the apps are running on two machines.
HTH,
-- ced
Scott J. Tringali
> What I want to know is: a better way ? What is wrong with signals ? Works
> ok, but I guess I want to fix it even if it aint broke;
> how do other people break these things ?
>
> My goal is to have two windows with two window cursors; if the mouse cursor
> is in one window,
> the window cursor in the other window is slaved to the main window
> through my rinky dinky mathematical algorithmic gizmo wizzardwiry.
Why deal with interprocess communication at all? Have both windows controlled
by a single thread in the same process.
Just write a program that multiplexes between two windows. Handle
communcations via variables and subroutines within your program. This kind of
stuff was possible before threads were invented.
You don't need a thread or process for each window. All that's going to do is
make it a hundred times harder. You might want to spend a little time
learning event-driven programming.
Dr d b karron
and not bogged by with
the other threads overhead.
Or on different machines, or in a cluster of machines.
"Scott J. Tringali" <scott.t...@etnus.com> wrote in message
news:3D4EBA5D...@etnus.com...