Re: shm_open ENAMETOOLONG
Re: shm_open ENAMETOOLONG
- Subject: Re: shm_open ENAMETOOLONG
- From: Terry Lambert <email@hidden>
- Date: Thu, 21 Aug 2008 18:34:34 -0700
On Aug 21, 2008, at 10:04 AM, Brian Bergstrand wrote:
On Aug 21, 2008, at 6:23 PM, Shawn Erickson wrote:
On Thu, Aug 21, 2008 at 8:20 AM, Shawn Erickson <email@hidden>
wrote:
On Thu, Aug 21, 2008 at 6:47 AM, <email@hidden> wrote:
I have been working on porting some POSIX C/C++ inhouse code to
OS X and have run into a problem with shm_open. It looks like the
size of SHM_NAME_MAX is 32 characters (noted on some older posts
here). Because our code specifies a file using a path, name and
PID, it usually exceeds this so I'm looking for any ideas to get
around this problem. Any thoughts on how to do this (using good
programming practices)?
A 32 character long hash of the path, name and pid?
Oops clicked send while trying to move the window...
Anyway consider an md5 digest in hex form or if you can handshake
consider a UUID.
man 3 md5
man 3 UUID
Actually, shm names are limited to 31 chars as the last byte is for
the NULL term. I've had a bug open since Mar 2006 to increase the
name size to 64bytes: rdar://4481762
It hasn't been addressed, and it won't be until we can deal with it in
a POSIX conformant way, without increasing wired memory, which just
naievely increasing the size of the structure by increasing the string
length would do.
When someone asks if they should use POSIX shared memory, we generally
tell them we prefer mmap'ed files, if you want a large path to things,
and that has the bonus of not taking wired memory, providing the same
string-based rendezvous, plus you can use FS permissions, including
ACLs, to protect access to the shared memory itself.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden