From: Steven Dake <sdake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] change thread-unsafe readdir to thread-safe readdir_r calls
Date: Wed, 07 Jul 2010 15:17:12 -0700 [thread overview]
Message-ID: <4C34FCE8.4070208@redhat.com> (raw)
In-Reply-To: <20100707214920.GN4630-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On 07/07/2010 02:49 PM, Jason Gunthorpe wrote:
> On Wed, Jul 07, 2010 at 02:24:45PM -0700, Steven Dake wrote:
>
>> Not sure how to map a readdir to readdir_r on a thread unsafe system...
>> perhaps with thread keys. In any regard, seems pointless, readdir_r is
>> there and what POSIX specifies for this purpose.
>
> Override opendir and allocate the buffer then and return a pointer to it
> through a custom 'DIR *'.
>
>>> FWIW, I've always considered readdir_r to be broken, you pass in a
>>> buffer without passing in a size and hope everything works out. Your
>>
>> I also have objections to some POSIX standard APIs - however, using
>> non-reentrant POSIX apis when reentrant POSIX APIs are available seems
>> counterproductive.
>
> Well, if the non-reentrant ones are badly designed I'm not sure it is
> a good trade.. Ie Solaris's man pages say:
>
> It is safe to use readdir() in a threaded application, so long as only
> one thread reads from the directory stream at any given time. The
> readdir() function is generally preferred over the readdir_r()
> function.
>
> Also see
>
> http://lists.grok.org.uk/pipermail/full-disclosure/2005-November/038295.html
>
> The horribleness of readdir_r is well documented, and is partly why
> libc's advocate thread safe readdir() desipte the existence of
> readdir_r.
>
>>> proposed patch to libibverbs is also not-portable because it uses
>>> NAME_MAX, not pathconf.. Sigh POSIX.
>
>> On bsd/solaris/darwin/linux, NAME_MAX is defined. Not sure which other
>> POSIX systems one would care about..
>
> If all you care able is bsd/solaris/darwin/linux then this is a
> non-problem, AFAIK they have sane libc's :) Ie I just checked and
> openbsd libc has been using a dynamic buffer allocated at opendir
> since 1996.
>
> If you care about theortical portability then you have to worry about
> NAME_MAX too..
>
Thanks I'll look into NAME_MAX for my server.
Regards
-steve
> Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-07-07 22:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-07 18:37 [PATCH] change thread-unsafe readdir to thread-safe readdir_r calls Steven Dake
[not found] ` <1278527821-14804-1-git-send-email-sdake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-07-07 18:52 ` Jason Gunthorpe
[not found] ` <20100707185257.GJ4630-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2010-07-07 19:14 ` Steven Dake
[not found] ` <4C34D208.1000705-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-07-07 20:47 ` Jason Gunthorpe
[not found] ` <20100707204712.GK4630-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2010-07-07 21:24 ` Steven Dake
[not found] ` <4C34F09D.6080908-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-07-07 21:49 ` Jason Gunthorpe
[not found] ` <20100707214920.GN4630-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2010-07-07 22:17 ` Steven Dake [this message]
2010-07-07 18:54 ` Roland Dreier
[not found] ` <adatyobyvg7.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-07-07 19:17 ` Steven Dake
-- strict thread matches above, loose matches on Subject: below --
2010-07-07 22:14 Steven Dake
[not found] ` <1278540873-3857-1-git-send-email-sdake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-07-08 18:27 ` Roland Dreier
[not found] ` <adalj9lzv4r.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-07-08 18:47 ` Jason Gunthorpe
2010-07-21 18:06 ` Roland Dreier
[not found] ` <adak4ooogjj.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-07-21 18:33 ` Steven Dake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C34FCE8.4070208@redhat.com \
--to=sdake-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).