MITSHM Extension...

[Lee Iverson]

Has anybody else actually tried to use this? I'm trying to setup for
shared images, but it seems that neither of the XShmQuery calls
actually checks that the server is on the same machine as the client.
Is there a simple portable way to do this? The documentation seems to
indicate that the XShmQueryExtension() call should actually do this,
but it doesn't and everything else works up until the XShmAttach()
call causes a protocol error, namely:

X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 129 (MIT-SHM)
Minor opcode of failed request: 1 (X_ShmAttach)
Serial number of failed request: 308
Current serial number in output stream: 309

This, of course, doesn't happen if the client and server are local to
the same machine. Aaaarrrggghhh! Any ideas?

--

Lee Iverson McGill Research Centre for Intelligent Machines
le...@mcrcim.mcgill.edu Computer Vision and Robotics Lab
McGill University, Montreal

[Mark Jeghers]

le...@thunder.mcrcim.mcgill.edu (Lee Iverson) writes:

>X Error of failed request: BadAccess (attempt to access private resource denied)
> Major opcode of failed request: 129 (MIT-SHM)
> Minor opcode of failed request: 1 (X_ShmAttach)
> Serial number of failed request: 308
> Current serial number in output stream: 309

>This, of course, doesn't happen if the client and server are local to
>the same machine. Aaaarrrggghhh! Any ideas?

Exactly! THe MITSHM extension is only meant for local clients (where it is
possible to build a shared memory bridge). It cannot be used over the network.

But, we can always wish, eh...:-)

[Lee Iverson]

ma...@netcom.com (Mark Jeghers) writes:

Not much of a clue, huh, Mark? Of course, I know it can't work over
the network, distributed shared memory is an interesting research case
but not yet available in SunOS :-) That's not my point. The docs for
the XShmQueryExtension() test seem to claim that it will only return
true if it can be used. That should include a test that the client
and server are on the same machine. It does not!

So again the question. Is there a simple test one can make to ensure
that an XShmAttach() request will not result in a protocol error? I
guess I will submit a bug report, but it would be nice if I had a
simple, portable fix.

[Burkhard Neidecker-Lutz]

In article <1992Apr8.1...@thunder.mcrcim.mcgill.edu> le...@thunder.mcrcim.mcgill.edu (Lee Iverson) writes:
>
>Is there a simple portable way to do this? The documentation seems to
>indicate that the XShmQueryExtension() call should actually do this,

No, the documentation doesn't say that. I tried at first to try to
decipher from DISPLAY whether I would be local, but that is error
prone and also messy when you deal with multiple possible transports.

When you think about it, all you are really interested is whether
the shared memory segment really exists (even if you're local, there
may be a limit on the number and size of such segments, meaning you
don't get one). So the logic I've used in my code is as follows:

do all of the setup, up to XShmAttach

XErrorHandler handler;

XSync(dpy,0);
attachfailed = 0;
handler = XSetErrorHandler(MyHandler);
XShmAttach(dpy, &sp->shminfo); /* Just try it */
XSync(dpy,0);

(void) XSetErrorHandler(handler); /* Critical time over */

where handler is the following routine:

static int attachfailed;

static int MyHandler(dpy,errorevent)
Display * dpy;
XErrorEvent * errorevent;
{
attachfailed = 1;
return(0);
}

If attachfailed is still 0 then it succeded, otherwise I need to clean up
the garbage at this point and go for a normal XImage instead.

Burkhard Neidecker-Lutz

Multimedia Engineering, CEC Karlsruhe
Software Motion Pictures
Digital Equipment Corporation
neid...@nestvx.enet.dec.com

[Lee Iverson]

nei...@kaputt.enet.dec.com (Burkhard Neidecker-Lutz) writes:

: In article <1992Apr8.1...@thunder.mcrcim.mcgill.edu> le...@thunder.mcrcim.mcgill.edu (Lee Iverson) writes:
: >
: >Is there a simple portable way to do this? The documentation seems to
: >indicate that the XShmQueryExtension() call should actually do this,
:
: No, the documentation doesn't say that. I tried at first to try to
: decipher from DISPLAY whether I would be local, but that is error
: prone and also messy when you deal with multiple possible transports.

:

Most of the answers I've received have suggested this method. I think
that the docs are at best ambiguous and at worst misleading.

: When you think about it, all you are really interested is whether

: the shared memory segment really exists (even if you're local, there
: may be a limit on the number and size of such segments, meaning you
: don't get one). So the logic I've used in my code is as follows:
:
: do all of the setup, up to XShmAttach
:
: XErrorHandler handler;
:
: XSync(dpy,0);
: attachfailed = 0;
: handler = XSetErrorHandler(MyHandler);
: XShmAttach(dpy, &sp->shminfo); /* Just try it */
: XSync(dpy,0);
:
: (void) XSetErrorHandler(handler); /* Critical time over */
:
: where handler is the following routine:
:
: static int attachfailed;
:
: static int MyHandler(dpy,errorevent)
: Display * dpy;
: XErrorEvent * errorevent;
: {
: attachfailed = 1;
: return(0);
: }
:
: If attachfailed is still 0 then it succeded, otherwise I need to clean up
: the garbage at this point and go for a normal XImage instead.

:
:

Thank you Burkhard, this is exactly the right answer. Clean and
predictable, however, I do feel that the XShmQueryExtension() should
do something akin to this. It doesn't seem much to ask that the
methods to test for extension availability over a display connection
should check that it is possible to use as well.