Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <20020606225327.59211.qmail@web21005.mail.yahoo.com> Date: Thu, 6 Jun 2002 15:53:27 -0700 (PDT) From: Nicholas Wourms Subject: SysV Ipc shm revisited...A new solution To: cygwin AT cygwin DOT com Cc: cwilson AT ece DOT gatech DOT edu, Ralf DOT Habacker AT freenet DOT de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/