Re: [CLucene-dev] thread problems / advice

[Isidor Z. <cl...@qu...>]

Hi Giorgio,

> 2009/7/28 Giorgio Zoppi <gio...@gm...>:
> >> We could also look into implementing that choice through policy
> >> classes, which should allow better compile time checks compared to
> >> preprocessor macros.
> > Currently i have some suspect with this code:
> >
> > At a given point in FSDirectory we have:
> >
> >  while ( true ){
> >          if( _unlink(nu) != 0 ){
> >            char* err = _CL_NEWARRAY(char,16+strlen(to)+1); //16: len of
> > "couldn't delete "
> >                strcpy(err,"couldn't delete ");
> >                strcat(err,to);
> >            _CLTHROWA_DEL(CL_ERR_IO, err );
> >          }
> >          //we can wait until the dir_Exists() returns false
> >          //after the success run of unlink()
> >          int i=0;
> >          while ( Misc::dir_Exists(nu) && i < 100 ){
> >            if ( ++i > 50 ) //if it still doesn't show up, then we do
> > some sleeping for the last 50ms
> >              _LUCENE_SLEEP(1);
> >          }
> >          if ( !Misc::dir_Exists(nu) )
> >            break; //keep trying to unlink until the file is gone, or
> > the unlink fails.
> >      }
> >
> 
> This seems that's not feasible to a fsync...isn't it?
> 

I think POSIX implementors are allowed to make fsync a no-op. And
other OSes might not even have it.

AFAIK, boost::filesystem's operations guarantee an appropriate
state of the file system as long as no race conditions are created, so
it might be interesting to see how they solve these problems.

Best regards,

Isidor