Solaris 10 doesn't like your fcntl.flock unlock
jblaine opened this issue · comments
In logster itself, end_locking(), the fcntl.LOCK_NB is unwelcome in the following call on Solaris:
fcntl.flock(lockfile_fd, fcntl.LOCK_UN | fcntl.LOCK_NB)
Using the following lets the code run at least:
fcntl.flock(lockfile_fd, fcntl.LOCK_UN)
The flock call in start_locking() works fine with LOCK_NB, of course:
fcntl.flock(f, fcntl.LOCK_EX | fcntl.LOCK_NB)
How would you like me to handle a patch for this?
- Is there really a need to specify LOCK_NB as an option with LOCK_UN? I've never really seen anyone do that before and can't see that it would be needed.
- Assuming it is needed, would you like me to import platform and query platform.system() to case the flock call if the result is 'SunOS' ?
I'm not sure if we really need LOCK_NB here, so I'd say adding a conditional based on the OS makes the most sense at the moment.
@jblaine did you eventually create a patch for this? How would you feel about submitting it as a pull request?
No, I didn't, but I sure can.
Yeah. Uh. Take the latter of those two: 3855c30
For the record: as suggested in #91, I submitted a pull request (#92) that adds support for locking files on Windows. This is done using the portalocker module.
portalocker.unlock() also works on Unix, where it internally calls fcntl.flock(fd, fcntl.LOCK_UN). Note that there's no fcntl.LOCK_NB.
That's in line with @jblaine's suggestion to merely use fcntl.LOCK_UN.