nanogui: Microwindows 0.88pre5 released
Subject:
Re: Microwindows 0.88pre5 released
From:
Morten Rolland ####@####.####
Date:
23 Mar 2000 18:03:10 -0000
Message-Id: <38DA6835.FF0A881E@screenmedia.no>
Thanks a lot for pre5! - It contains quite a few goodies we will look
into over the next few days... can't wait...
Greg Haerr wrote:
>
> o Added shared memory support for Nano-X client/server to eliminate need
> for local UNIX socket. Shared memory support is turned on with a new
> HAVE_SHAREDMEM_SUPPORT config option, and a call after
> GrOpen to GrReqShmCmds. (thanks Morten)
The shared memory support will not eliminate the need for a local
UNIX socket, but most of the drawing requests will be transfered
through shared memory, which is a lot faster. All data going from
the server to the clients are still transfered over the socket.
Some of the more bulky return traffic can probably be made to use
the same shared memory as well, but this is for later.
There where some problems with the shared memory patch and the
async protocol patch. The supplied patch should be applied to
fix these issues; sorry for not figuring this out before sending
the previous patches. Other than that - it seems to work well.
The patch is against pre5 of course:
* Shared memory would fail because of an uninitialized pointer
in the client structure in the server. You know that shared
memory is used when nano-X displays something like:
Shm: Request key granted=1000000
(If it reports key granted=0, there was an error allocating
a shared memory segment, and old socket transfers are used).
If someone can help me with a better key allocation strategy
or insight into how it was originally intended, I'd be
thankful. I remember something vaguely about files, their
inodes and the minor block device number... Might be wrong here.
The nano-X server only tries to allocate from key=1000000 and
upwards, for a total of 256 tries before it failes. Should
work well on any embedded system, at least.
* The shared memory segments was not detached, so they floated around
until nano-X exited. With this patch, the shared memory segment is
released when the client connection is closed. Use the 'ipcs'
tool to list the shared memory segments allocated. Warning: They
may stay around after the last process that used them has exited.
They have to be explicitely destroyed, unless I'm mistaken. Now,
the shared memory is marked for destruction by the client once
the shared memory has been mapped (to prevent other apps from
mapping and reading/writing the shared memory - there is a small
window of vulnerability here, but it should work for now).
When the client dies, the server also marks the segment for
destruction and detaches it. This should prevent any shared
memory from not being released.
* When the nano-X server exits, the clients will now exit(1) as
well, with a message to stderr: Nano-X lost connection. The
problem was a slipup in GrReadBlock, where an End-of-file
condition was not detected (read returns zero). Thanks to Greg
for discovering this and telling me.
Note: Only some of the nano-X demos usees the shared memory thing:
world, landmine and demo.
Also: Some of the debugging and informational messages should be
removed, eventually, but they should be left in there until more
people have had the time to try it out, I think.
Regards,
Morten Rolland, Screen Media
[Content type application/octet-stream not shown. Download]
