nanogui: IPC client/server comm.
Subject:
Re: IPC client/server comm.
From:
####@####.####
Date:
30 Mar 2000 14:36:34 -0000
Message-Id: <20000330142638.26168.qmail@nameplanet.com>
On Wed, 29 Mar 2000 23:20:22 -0700 "Greg Haerr" ####@####.#### wrote:
>: In the context of a client/server model in nanox, I was wondering what
>: is the benefit of using sockets (with an IP stack) for communications
>: between the client and server if the client AND the server runs on the
>: same CPU/machine ?
>:
>The socket is an AF_UNIX local socket, so it doesn't use the IP
>stack or localhost.
>
>However, I see your idea. Perhaps Morten and/or Vidar could comment
>on how well pure SysV IPC could be used without any unix sockets.
I'm not sure, but I don't think you'd see that much of a speedup over
Mortens shared memory patch. You would still have the overhead of context
switching, and Unix domain sockets are fairly lightweight to start out
with.
>
>: Do you think integrating that communication mechanism in nanox would be
>: difficult/long/annoying ? (I know that Morten already contributed shared
>:
>: mem support)
>
>I'm also interested in another option: direct client framebuffer mapping. This
>would allow the client process to write the framebuffer directly. It would
have
>access to shared code and data that would setup the appropriate clip
>regions so that window heirarchies would be maintained...
I'm not sure about direct framebuffer mapping, but you would get a long way
by just adding support for off screen pixmaps in the client address space,
and use blitting. This would be a great plus for the flash player and for
porting libraries like SDL... This is on my todo list, but unfortunately
I had to bump it a few places down due to some extra work on other stuff, and
don't know when I'll get time to look at it.
Vidar.
--
Get your firstname@lastname email for FREE at http://NamePlanet.com
