Mail Archives: cygwin/2002/06/07/11:51:35
> -----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/
- Raw text -