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: "Ralf Habacker" To: "cygwin" Subject: RE: MIT shared memory extension Date: Fri, 17 May 2002 12:29:37 +0200 Message-ID: <00da01c1fd8d$bea22d00$651c440a@BRAMSCHE> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 CFLAGS=-I/usr/local/include LFLAGS=-L/usr/local/lib -lcygipc $ make or on the command line $ CFLAGS=-I/usr/local/include LFLAGS=-L/usr/local/lib -lcygipc make compiling with cygipc code Makefile CFLAGS=[-DUSE_CYGIPC_IPC] # if different key_t type LFLAGS= $ 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/