Mail Archives: cygwin/2002/06/07/16:39:16
Robert Collins wrote:
> 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.
Okay, yeah -- you'll always have to reLINK your application when
switching between the two servers. But if both cygdaemon and cygipc2
use a 64 bit key, then at least you won't have to reCOMPILE your source
code...right?
The RPC function signatures are identical...nope, they aren't. Neither
are the structures...I think this means you'll always have to reCOMPILE
client source code in addition to reLINKing it.
example: char * vs. const void *, int vs size_t
cygdaemon:
void *shmat(int, const void *, int);
int shmctl(int, int, struct shmid_ds *);
int shmdt(const void *);
int shmget(key_t, size_t, int);
ipcdaemon:
char *shmat (int shmid, char *shmaddr, int shmflg);
int shmctl (int shmid, int cmd, struct shmid_ds *buf);
int shmdt (char *shmaddr);
int shmget (key_t key, int size, int flag);
Also, the ipcdaemon structure shmid_ds has some extra fields, as
compared to the cygdaemon version -- and even the fields that they have
in common are in different orders.
> 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.
Actually, a 64bit-key_t-using libcygipc2 would mean that you don't need
to "switch" types.h. Just sem/shm/msg/ipc.h -- which is as easy as
adding -I/usr/local/include to CFLAGS or not.
But, it seems as though there are LOTS of differences between the
cygdaemon implementation and the ipcdaemon implementation (this is good,
because frankly, ipcdaemon sucks).
So you'll ALWAYS have to recompile and relink your app when switching
between ipcdaemon on cygdaemon.
<rhetorical>
So what was all the fuss about 32bits versus 64bits on key_t? Seems
like that's just a drop in the ocean of differences...
Ah! the fuss was because "key_t" is defined in newlib's types.h file --
which will almost always get included when compiling ipc programs. But
this definition conflicts with what the CURRENT libcygipc.a and
ipcdaemon.exe think...so newly compiled, cygipc-based apps will ALWAYS
break (at runtime maybe, but more probably at linktime due to
conflicting definitions)...more below.
</rhetorical>
> They can already run both. I've tested this BTW.
And the sensei speaks...
> Already provided. What will happen when the 64 bit key is exported is
> that fresh cygipc linked programs will fail,
because the new program, even though it uses libcygipc, will see the
cygdaemon-inspired newlib 64bit definition for key_t, but ipcdaemon
itself, running in the background, will think that key_t is 32bits --
because it was built before newlib defined key_t. Mismatch between
client and server == crash. Okay, I get that.
> but existing programs will
> still work correctly.
Right, because both were compiled back before the cygdaemon-inspired
change to newlib's types.h which declared key_t to be a 64bit value.
> If something like ipcdaemon2.exe exists - OR -
> cygipc is re-released as a 64-bit version, then new links will succeed
because the daemon and the newly-build client and libcygipc2 library,
will all agree that key_t is 64 bits.
> (but at the possible cost of breaking old binaries).
Right -- maybe. old binaries will try to talk to ipcdaemon -- but
unless I change the handle ID strings (in IpcNtLit.h), both ipcdaemon
and ipcdaemon2 will answer the same requests -- but one will "know" that
the key_t is 32, but the other deamon will think that key_t is 64bits ==
boom.
So, I'd need to insure that
1) ipc-daemon.exe and ipc-daemon2.exe can coexist
--> change the ID strings and filenames in IpcNtLit.h, so that new
programs use a different ID string when contacting the server, and the
new server answers to that new ID string.
2) teach ipc-daemon2 (and libcygipc2) that key_t is 64 bits.
However, in this scenario, there's really no reason for the library name
to change. (But the daemon name MUST change). The old library, the
current libcygipc.a, will be completely useless after cygwin-1.3.11 is
released. So, I might as well let the new (functional) library be
libcygipc.a -- that way, existing programs that use libcygipc.a can
still -lcygipc and won't need to change their build process to -lcygipc2
or somesuch. But, so that people can have both cygipc daemons
running/installed on the same system, the daemon name must be different.
Furthermore, this modification of the cygipc interface is not "so that
people can switch between cygipc and cygdaemon versions easily" -- that
still won't be easy, unfortunately. The mod is necessary "so that you
can actually build and link cygipc programs under cygwin-1.3.11".
Did I get that right, sensei?
--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/
- Raw text -