On my Solaris 8 box test_fcntl succeeds just fine (just tried it again), with no hangs or hesitations - on the other hand, it's not using any NFS filesystems, so that could be the problem with the SF box. So declare the box broken... I'd be inclined to update the test anyway, since most people who want to lock files will use the supplied flock()/lockf() rather than doing it the hard way - so if the fcntl test locks files, it should use the generic locking functions. Guido van Rossum wrote: > > While testing Python 2.1 on SF's Solaris 8 box, I noticed that it > hangs forever in test_fcntl, on this line: > > rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, lockdata) > > Why could this be? Could it be that the NFS lock server is stuck? > > But I could also note that this test is pretty silly. It has all this > platform-specific cruft to do a locking operation the hard way, while > the fcntl module supplies two operations (flock() and lockf()) that > could be used instead! > > (Unfortunately, using lockf() I get the same behavior -- not > surprising, since the C code does the same thing that the Python code > was doing. :-( ) > > Should I update the test, or declare the machine broken? (I *think* I > recall that the tests succeeded yesterday.) > > --Guido van Rossum (home page: http://www.python.org/~guido/) -- Mark Favas - m.favas@per.dem.csiro.au CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4