RE: MIT shared memory extension

["Ralf Habacker" <Ralf dot Habacker at freenet dot de>]

> This is off-topic for the xfree mailing list, it's really a developer or
> general topic. Anyway....

Should we move this to the cygwin list ?  I'm not subscribed to the develop
list.
> > 1. Why do you use st_dev explicity. Isn't ftok() only for
> > files ? From the ftok documentation: "The ftok() function
> > returns a key based on path and id that is usable in
> > subsequent calls to msgget(), semget() and shmget(). The path
> > argument must be the pathname of an existing file that the
> > process is able to stat()."
> >
> > So st_dev seems to make no sense for me and could be removed.
>
> Possibly. If the file can be stat'd - and devices can - we should check
> it, no?

Yes, this can be done after the stat() call.

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

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

BTW: I have additional looked into the cygipc implementation. They uses only the
lower word of st_ino and lowest byte of st_dev and lowest byte of id. And this
seems to work, although the must have this hash collision problem even more,
doesn't it ?  May be this is another way to prevent the newlib patch.

Regards
Ralf