> > Thats all. No patching headers. This enables migrating one > > package to cygwin ipc stuff, while other packages could use > > the cygipc stuff. > > We still need to do the ABI upgrade though, before that can be done.
You mean building a new cygwin1.dll with shm support ? I have patched sys/types.h key_t definition with #ifdef _CYGIPC_IPC_ typedef long key_t; #else typedef long long key_t; #endif have applyed the cygwin.din patches, have recompiled and installed cygwin1.dll in /usr and than I can compile an app using cygipc and another using cygserver. What's additional to do ? So the only thing to do I see is to distribute a new cygwin release with shm support. > > > 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. > > Interesting. How to read the results? (is lower better or worse?). > This results are produced by the profiler lib located in the http://kde-cygwin.sf.net cvs area n = nummer of running tests min = minimal measured time for one test max = maximal measured time for one test avg = average time of all tests sum = accumulated time for all tests the results are in usec > Also, as you can read both codes without issue, would you care to > document how the cygipc one is much faster? Hmmh, I have only some assumption, but I will think about this. BTW: What about a new binutils release. Is this going on ? 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/
