develooper Front page | perl.perl5.porters | Postings from March 2001

Re: flock() on dup'ed filehandle is not enforced

Thread Previous | Thread Next
From:
nick
Date:
March 28, 2001 11:03
Subject:
Re: flock() on dup'ed filehandle is not enforced
Message ID:
E14iL9D-0003em-00@roam1
Mark-Jason Dominus <mjd@plover.com> writes:
>> Silly question - but do the failing suns have the files in question on NFS
>> mounts? - if so do the NFS servers have the flock daemon working?
>
>I did my test on /tmp, which was not nfs-MOUNTED.

But is often tmpfs which tends to have odd semantics of its own.

>
>Gwyn Judd says in clp.misc that the problem is as follows: The Perl 
>        open STDOUT, ">>&F"
>operation does not correspond to 
>
>        close(1);
>        dup2(6, 1);             /* here fileno(F) == 6 */
>
>Instead, it does:
>
>        dup(6);                 /* yields 7 */
>        dup2(7, 1);
>        close(7);                  

That weirdness is retained in bleadperl. The logic seems to be 
not to disturb stdin..stderr until we know whole "open" process is going
to work (and with PerlIO layers and such there is more scope for 
things not working out - hence I kept it).
(Or it may be because there is an fclose()-oid call in there due
to perl's PerlIO */FILE * fixation, and the extra dup is to avoid
a FILE * with no fd.)

I guess one could do:
         oops = dup(1);   // just in case 
         close(1);
         if (dup2(6,1) == 1 && ...)
          close(oops);
         else
          dup2(oops,1)       
           
>        
>According to Gwyn, the close(7) releases the lock on the file, and
>this semantics is mandated by POSIX.  If this is true, then it only
>works on Linux because of a bug in Linux!

Makes sense.

-- 
Nick Ing-Simmons


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About