Roland Mainz wrote:
> On Tue, May 6, 2008 at 2:09 PM, Glenn Fowler <gsf at research.att.com> wrote:
>
>> On Tue, 6 May 2008 13:45:24 -0700 Roland Mainz wrote:
>> > Just asking to be sure: |fts_open()|/|fts_read()|/etc. do not write to
>> > any global variables within libast and is supposed to be threadsafe
>> > assuming each thread manages it's own |FTS *| handle, right ?
>>
>> each fts state is entirely in the fts_open() handle
>> to be thread-safe all or all but one caller must use FTS_NOCHDIR
>>
>
> Ok... that was the main issue I was worried about - I'd like to make
> sure all ARC-contracted (or somehow else ARC'ed) interfaces be
> threadsafe and maybe take a |flags| field (if appropriate) to make
> sure we can adjust the API later on demand. Both items apply to the
> |libast::ftp_*()| stuff which means it's IMHO Ok to open the
> interfaces for ARC contracts (or something higher in the ARC stabilty
> stuff).
>
One of the reasons I would prefer to use fts_* directly rather than
ftwalk() is the thread safety.
With fts_open(), fts_read() my function can know its own context, with
ftwalk() or nftw() a commonly available user function must resort to
globals. (The static fts_compare state in ftwalk() also looks like a MT
problem.)
With the fts_* design, the one MT issue I see is in the comparator,
(it does not matter in my context since there are no thread/context
specific behaviors to my comparator,) but for general cases the
comparator should probably have been given access to a void * registered
on fts_open().
>
>> if the system imposes a PATH_MAX limit then FTS_NOCHDIR will
>> limit search pathname depth to PATH_MAX
>>
>> FTS_NOCHDIR limitations could be handled by opendirat()
>> but the ast fts implementation does not iffe for opendirat() yet
>>
>
> AFAIK that's not needed right now (e.g. it can be done much later in
> the ksh93t or ksh93t+ development cycle).
>
My only concern for thread safety is that I want to move the
traversal into a project private library with no statics so it is always
as thread safe as the underlying libraries. I don't think we'll need
the actual thread safety for some time.
Thanks,
-Will
> -----
>
> Bye,
> Roland
>
>
