Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Subject:	RE: MIT shared memory extension
MIME-Version:	1.0
Date:	Fri, 10 May 2002 23:20:30 +1000
X-MimeOLE:	Produced By Microsoft Exchange V6.0.5762.3
content-class:	urn:content-classes:message
Message-ID:	<FC169E059D1A0442A04C40F86D9BA7600C6044@itdomain003.itdomain.net.au>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
From:	"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To:	"Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>,
	"Cygwin" <cygwin AT sources DOT redhat DOT com>
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id g4ADKsY06459

> -----Original Message-----
> From: Ralf Habacker [mailto:Ralf DOT Habacker AT freenet DOT de] 
> 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 
> > > (CASE1) adding an ascii representation of id to the path 
> and calling 
> > > hash_path_name() (the function which creates
> > > statbuf.st_ino) or (CASE2), using id as hash value for
> > > hash_path_name() like the following code.
> >
> > hashs collide. key_t's can not collide under any circumstance, and 
> > must be deterministic (i.e. not dependent on currently issued keys).
> 
> But how do you ensure this in the current implementation ? 
> st_ino contains a hash value. So this problem concerns the 
> current implementation and the suggestion I've made.

The st_ino is meant to be unique per device. So the st_ino + the device
number that the file is on is unique. If the cygwin st_ino gives
problems, we've at least made it as minimal chance as possible. Reducing
the search space will increase the chance of key_t collisions.
 
> >
> > How do you suggest that you avoid hash collisions?
> 
> With my suggestion I haven't adressed the problem of avoiding 
> hash collisions. I only have addressed the newlib patch you 
> suppose. Sorry :-(

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.

Rob

--
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 -