[GRASS5] New IPC XDRIVER vs. fifo vs. UNIX Sockets???
neteler at geog.uni-hannover.de
Thu Nov 16 04:43:03 EST 2000
Hi Eric, hi all,
On Sun, Nov 12, 2000 at 09:47:13PM -0800, Eric G . Miller wrote:
> As we look to implement this new IPC messaging XDRIVER, it's come up
> that some *nix variants may not support SYSV message queues. That's
> kind of a problem since the whole idea is to improve compatibility and
> possibly performance. Unfortunately, the FIFOs don't work under CygWin
> (correct ?). So, a third alternative is using sockets.
Up to now the "new" IPC messaging XDRIVER has not been announced
here, it was somewhat unofficial. Huidae Cho has implemented the
IPC messaging XDRIVER from Ronald Wiemer (from 1994, developed for
GRASS4.1). Myself I was misleaded and thought it would be a sockets driver,
therefore former mails might have been confusing.
CygWin does not support fifos, therefore it is very important to get rid of
the fifo XDRIVER/CELL driver etc.
The current IPC messaging XDRIVER is somewhat working, but has severe bugs
which would have been to be fixed. But some platforms might not support
message queues (like Macintosh?). So we should not concentrate on it.
> I've been rummaging around and noted that:
> a) CygWin apparently supports UNIX sockets (presumably both AF_INET and
> b) Virtually all *nix's support local UNIX sockets (is this not true?).
> c) XFree86 4.0.1 runs under CygWin now (haven't looked at details).
So it seems that sockets would be the only option to be platform
independent. Maybe the new IPC XDRIVER could be again modified to sockets,
at least we know, where changes are required.
Eric already tried that:
> So, I've been playing with updating parts of necessary code to use local
> unix sockets (AF_LOCAL, sockaddr_un). Anyway, I'm no expert in this
> area, but think this could be a viable solution (if it's decided that
> portability for the IPC mechanism is a problem). However, several
> bits of code would have to change, because:
> a) The whole fifo thing would have to disappear.
> b) The socket file must not exist before bind() is called. This
> would necessitate a change in many of the semantics for testing
> whether a monitor is running or not.
> c) Only one file descriptor is needed.
> d) Need to be able to pass around a 'struct sockaddr_un'.
> e) There'd need to be a different mechanism for identifying the
> socket file associated with the monitors (perhaps some different
> environment variables?).
> f) Other things I haven't thought of or come across...
> I've focused on local sockets only because it reduces some of the
> security checks that are necessary. Anyway, I know some of you problem
> have more experience with this stuff than I, so I'd appreciate any
Me, too :-)
If the others agree to change the XDRIVER to sockets, we should go for it.
In my opinion a Windows port is very important for the reputation of GRASS.
And it announced such a long time... We should finish it: "just" the XDRIVER
is missing, the modules are already working on CygWin. But a GIS without
graphical output is not much fun.
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev