This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]