Re: SysV Ipc shm revisited...A new solution

[Charles Wilson <cwilson at ece dot gatech dot edu>]

I'm reading this thread top-down, so if I say something that has already 
been addressed in a different followup to Nicholas's message, I 
apologize for the repetition.  If, as I read down this thread, I see 
something that I've addressed in THIS reply, I will NOT make an explicit 
reply that says "I addressed this point in my original message".  So, 
read THIS message carefully...

If there were any misunderstandings between Nicholas and I, no worries 
from my end.  He's not talking out of school...but merely expanding on a 
single sentence in a private email.  I encouraged him to do so -- but 
it's possible he "expanded" in a direction I didn't intend.  But that's 
okay...

Nicholas Wourms wrote:

[background snipped]



> 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.

Sortof.  In my view, cygipc-2 would NOT be an official part of the 
cygwin dist.  It would, just like the current cygipc, live over on the 
cygutils website.  BUT, it would be compatible with the 64bit keysize 
used be cygdaemon.  That way, if for instance Jason recompiled postgres 
against cygipc2, then (hopefully) folks could use THAT version of 
postgres with EITHER ipcdaemon2 OR cygdaemon, without having to 
recompile postgres (and NOT having to recompile their kernel).

This would enable testing of the new cygdaemon with existing code -- but 
still would "keep the heat on" for a stable cygdaemon, since cygipc2 is 
STILL not a real part of the cygwin dist.


> 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. 

Okay, this part I disagree with.  The *only* extant exception, where an 
official cygwin package is allowed to depend on a non-cygwin package, is 
postgres.  I don't want to add X to that list, and I don't want cygipc2 
to be an official cygwin package.

I just want to make it easier for people to TEST stuff against cygdaemon 
-- IF they want to do so.  By mandating that Harold compile his X 
packages against cygipc2 (or cygdaemon) we then REQUIRE everybody who 
wants to run X to install an IPC daemon.  Currently, the only fully (?!) 
functional one is cygipc(2?).

But that is not an official package.  I don't want to make it an 
official package.

In my view, with the "new" cygipc2 off-site package, interested parties 
like the KDE folks can recompile X -- like they are doing now.  BUT, if 
they do so, then they could cleanly SWITCH between cygipc2 and cygdaemon 
without a SECOND recompile.


> 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,

True -- and not a good thing.  I *want* that barrier -- because its 
presense serves as a painful reminder to HELP GET CYGDAEMON WORKING!!! <g>



> 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.

Not entirely true.  It would FORCE people who want to use X to install 
an extra package, and run a background daemon.  Lots of folks don't want 
to do that...like me. <g>

[snip]


> 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. 

Yep.  But in my view, no official cygwin packages except for postgres, 
would depend on cygipc2.  If you want to play with ipcdaemon/cygdaemon, 
you still need to compile your app with the appropriate flags to do so. 
 Even if that app happens to all of XFree86.

--Chuck


--
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/