SysV Ipc shm revisited...A new solution

[Nicholas Wourms <nwourms at yahoo dot com>]

Ok,

I hate to rehash an old discussion, but some private discussions with
Chuck have brought a new solution to light on an old problem.  Basically
we have a problem with certain applications requiring (or operating poorly
without) IPC.  It is quite evident that the new cygserver is a WIP -- very
unstable at the moment.  The only option was to use cygipc, which is a
fairly stable solution.  However, by doing so, your application would then
be dependant on the cygipc implimentation due to the 32bit vs. 64bit key
difference in cygipc and cygserver.  By enabling the 64bit key, all apps
built with a 32bit key would be broken when using the new cygserver. 
Obviously this has created quite a problem for many, as it doesn't provide
an easy solution when the key is switched over.  Anyhow, what we need is a
solution that provides reliable shared memory support in the main
distribution without the incompatibilities.  Furthermore, it would have to
be a solution which allowed switching between it and cygserver on the fly,
if necessary (to further testing of cygserver).  Here is the solution that
Chuck and I propose:

Distribute a package called cygipc-2:
1)It would contain a library libcygipc2.a which would be based on the
64bit key and compatible with cygserver's version.

2)ipc-daemon2.exe would peacefully co-exist with the cygserver.exe,
allowing a person to run either daemon (but not both) provided they had
turned on the 64bit key in cygwin.

Chuck says implimenting this package wouldn't be too much trouble, and is
willing to do so.  Now why, you ask, should we do so?  Simple, considier
all the dependancies it would satisfy.  Take, for example, X11, which is
currently compiled without SHM.  This, alone, prevents many of the more
advanced window managers from operating, not to mention some of the X11
applications which require shared memory.  However, with this solution,
Harold could rest assured that if he compiles X against cygipc2, it would
be compatible with cygserver, in its final form.  I'm sure there are many
more instances where this would be of use, but I think it comes down to
one point.  It removes the barrier for application development efforts,
while still allowing the continued testing and furtherment of the core
cygserver code.  It would provide a path for people to migrate to the 64
bit key, but at thier own pace.  This would be controlled by allowing
people to download 64bit key enabled snapshots, provided they had no
applications that were dependant on the legacy 32bit key enabled cygipc. 
Or, if they wanted to, they could compile the support in via a configure
option.  Then they could test the new cygserver, or if they found it too
unstable, revert to the cygipc2 server without having to change
cygwin1.dll's.  Choice is important, and is a the core of Free Software,
so why not give people more choices?  The fact is that the solution is
there, all Chuck needs is the green light...

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/