Re: Equivalent of openat() on osx?
Re: Equivalent of openat() on osx?
- Subject: Re: Equivalent of openat() on osx?
- From: Paul Nelson <email@hidden>
- Date: Tue, 03 May 2011 13:34:30 -0500
On May 3, 2011, at 12:45 PM, Tilghman Lesher wrote:
> On Tuesday 03 May 2011 11:13:09 Anatol Pomozov wrote:
>> I am porting a Linux program to macosx (target is 10.6 version) and
>> the program uses openat/unlinkat/... functions. Although these
>> functions are not in POSIX, they are widely used on *nixes and the
>> part proposal the next POSIX.
>>
>> My question what is the best equivalent for the opentat() functions
>> that can be used in multithreaded application. Currently I use
>> something like this:
>>
>>
>> int openat(int dirfd, const char *pathname, int flags, ...)
>> {
>> int fd;
>>
>> if(fchdir(dirfd) < 0) {
>> perror("fchdir");
>> return -1;
>> }
>> fd = open(pathname, flags, mode);
>> // chdir to the original CWD
>> return fd;
>> }
>>
>> But this is not a perfect solution - current working directory is
>> shared among all threads, it means that openat() may affect other
>> threads. Is there an equivalent of this implementation without
>> changing the current directory?
>
> If you aren't using chroot(2) (or moving directories) in your application,
> you can do this. Wrap calls to opendir(2) and closedir(2), mapping
> descriptors to directory paths (and disposing of them), then in your *at()
> functions, remap the relative pathname back to an absolute pathname.
> You're right that this isn't a perfect compromise, but I think it should
> work, with the caveats above.
This is exactly what openat is supposed to avoid. You don't want to use a path that is stale in the open call. If you are using openat, you probably have a reason for it. The directory fd passed in might get renamed before the open can be called.
I think the poster was on the right track with fchdir, assuming they also use open(".", O_RDONLY,0) to save the current wd. This will guarantee that the folder does not disappear before the open call happens. I would use pthread mutexes to protect the fchdir stuff, and you might consider something more sophisticated when you receive a blocking open call so the mutex doesn't get held too long. Also, avoid using getcwd, as it is a performance pig.
This way, the open should not fail because the path argument is invalid, which is what openat is designed to do.
To avoid having an init function for your mutex, use pthread_once from inside your openat when you find that the mutex is uninitialized.
>
> Alternatively, you can use a global mutex in your *at functions, ensuring
> that only one thread is accessing the environment path, but that
> potentially creates a major bottleneck.
>
> --
> Tilghman
_______________________________________________
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