Mail Archives: cygwin/2002/05/17/06:31:54
I have prepared some more informations about this topic and before this is lost
I send it to the list for archive purpose. :-)
> I don't see anything wrong with the patch :}. Unless cygipc get's
> dll'ised, an app can only link against one of cygipc or the cygwin1.dll
> implementation. When we release the cygserver IPC code, folk will have
> to recompile *anyway* to get the new functionality, and existing users
> won't be affected.
>
> For developers that want to mix and match, they can do the following:
>
> install cygipc.
> backup:
> sys/types.h
> ipc.h
> sem.h
> shm.h
> cygipc.a (and remove from the disk)
> libcygwin.a
> to a cygipc_backup tarball.
>
> patch newlib's sys/types.h.
> rebuild cygwin with the dll export patch included.
> install cygwin.
> backup:
> sys/types.h
> libcygwin.a
> ipc.h
> sem.h
> shm.h
> to a cygwin_ipc tarball.
>
> Now you can with a little effort switch between the cygwin and cygipc
> versions for compile time. For runtime there is no conflict.
>
What about (debug-)printing ftok() returnvalue. I have written a testcase and
have to do a
#ifdef IS_CYGWIN_IPC
printf("%ull",key);
#else
printf("%x",key);
#endif
But where to get the IS_CYGWIN_IPC ?
I see an easier way to archive this. But this depends on an identical key_t
type, which goes like the following (assuming, that cygwin ipc functions are
exported, probably in the next cygwin release ?):
install cygwin (ipc header goes into /usr/.. )
install cygipc (ipc header goes to /usr/local/.. )
so they can coexist. If the key_t are the same the only difference is a CFLAGS
and LFLAGS setting
compiling with cygipc
Makefile
<snip>
CFLAGS=-I/usr/local/include
LFLAGS=-L/usr/local/lib -lcygipc
<snip>
$ make
or
on the command line
$ CFLAGS=-I/usr/local/include LFLAGS=-L/usr/local/lib -lcygipc make
compiling with cygipc code
Makefile
<snip>
CFLAGS=[-DUSE_CYGIPC_IPC] # if different key_t type
LFLAGS=
<snip>
$ make
or
on the command line
$ make
Thats all. No patching headers. This enables migrating one package to cygwin ipc
stuff, while other packages could use the cygipc stuff.
BTW: This is another thread, but perhaps it is interesting for somebody to see.
Below there is a first performance measurement of cygipc relating to cygserver
shm support. Only for info.
cygipc
$ ./shmtest
[2732] ftok n: 1000 (min) 493 (max) 13029
(avg) 542 (sum) 542854 [us]
[2732] shmget-create n: 1000 (min) 6 (max) 429
(avg) 8 (sum) 8335 [us]
[2732] shmget-client n: 1000 (min) 4 (max) 88
(avg) 4 (sum) 4952 [us]
[2732] shmat n: 1000 (min) 289 (max) 2611
(avg) 310 (sum) 310613 [us]
[2732] shmdt n: 1000 (min) 53 (max) 253
(avg) 57 (sum) 57999 [us]
cygwin
[2744] ftok n: 1000 (min) 683 (max) 13070
(avg) 799 (sum) 799012 [us]
[2744] shmget-create n: 1000 (min) 4167 (max) 70520
(avg) 4674 (sum) 4674595 [us]
[2744] shmget-client n: 999 (min) 3949 (max) 14792
(avg) 4339 (sum) 4335377 [us]
[2744] shmat n: 1000 (min) 525 (max) 5368
(avg) 793 (sum) 793522 [us]
[2744] shmdt n: 1000 (min) 597 (max) 15676
(avg) 665 (sum) 665580 [us]
Regards
Ralf
--
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 -