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 From: "Robert Collins" To: "'Nicholas Wourms'" , Cc: , Subject: RE: SysV Ipc shm revisited...A new solution Date: Sat, 8 Jun 2002 01:46:44 +1000 Message-ID: <009e01c20e3a$867fa700$0200a8c0@lifelesswks> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal In-reply-to: <20020606225327.59211.qmail@web21005.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal > -----Original Message----- > From: cygwin-owner AT cygwin DOT com > [mailto:cygwin-owner AT cygwin DOT com] On Behalf Of Nicholas Wourms > Sent: Friday, 7 June 2002 8:53 AM > It is quite evident that the new cygserver is > a WIP -- very > unstable at the moment. Yup. Actually the cgyserver itself is quite stable, it's the IPC code that is bleeding edge at the moment. (IMO). > 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. There is much more than that to the difference. At a minimum the link library and/or dll import is an issue, at maximum the RPC style used to talk to the daemon is an issue. Unless the RPC stubs for cygserver and cygipc are identical - which they are not irrespective of the key_t size - you will always have to relink your application when you switch from one IPC server to another. Mind you, they can co-exist and run at the same time. > 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: That is already available and documented - to the extent that it is physically possible. (i.e. (Boot; Start cygserver; Start cygipc; While testing do{ A) switch types.h;sem.h;shm.h;ipc.h; to appropriate copy. B) rebuild your app. C) test it. } > 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. Ok. This is doable, but won't reduce the headaches above. > 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. They can already run both. I've tested this BTW. > 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 ... > one point. It removes the barrier for application > development efforts, Nope. It doesn't. Nice try though, and I'm sorry it won't work. > 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. Already provided. What will happen when the 64 bit key is exported is that fresh cygipc linked programs will fail, but existing programs will still work correctly. If something like ipcdaemon2.exe exists - OR - cygipc is re-released as a 64-bit version, then new links will succeed (but at the possible cost of breaking old binaries). Rob -- 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/