> I don't think that the next cygwin release should enable the code. It's
> not ready yet - it's apparently high latency, and needs further work.
but latencies seems to me a generic problem. I remember the lmbench result, for
example context switching
http://sources.redhat.com/ml/cygwin/2002-01/m
> I don't think that the next cygwin release should enable the code. It's
> not ready yet - it's apparently high latency, and needs further work.
it may not be the fasted but it seems to work, isn't it ? Why not marking this
feature as alpha stage or so.
Users are able to use it for evalating and
> -Original Message-
> From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 17, 2002 9:58 PM
> To: Robert Collins; cygwin
> Subject: RE: MIT shared memory extension
>
>
> > > Thats all. No patching headers. This enables migrating
>
> BTW: What about a new binutils release. Is this going on ?
Indeed, it does beg the question, what about the "removing unused "_nm_"
symbols fix" and "objdump/cygwin crashes on auto-imported libs"? discussed
in the following threads:
http://sources.redhat.com/ml/binutils/2002-04/msg00395.html
ht
> > 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/
> -Original Message-
> From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 17, 2002 8:30 PM
> 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, probabl
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 r
...
> In short, I don't like the idea of making key_t 32 bits.
...
> Now you can with a little effort switch between the cygwin and cygipc
> versions for compile time. For runtime there is no conflict.
>
Okay, I have tried to give you some ideas to avoid 64 bit key_t, but it seems,
that you reall
> -Original Message-
> From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 10, 2002 10:20 PM
> Should we move this to the cygwin list ? I'm not subscribed
> to the develop list.
Done.
> > > 2. Does st_ino creates uniq inodes rsp. hash values ? If
> so, why not
> > >
9 matches
Mail list logo
