oblique / named-lock Goto Github PK

Hello! My program fails with CreateFailed if compiled using musl instead of glibc on Linux.

Is there something I can do to aid debugging here? Thanks

/tmp gets cleaned on macOS periodically which breaks long running applications holding locks. I assume other unix platforms might have similar problem.

For example, if a lock is named /one/two the file will be created at /one/two.lock.

I actually think this is quite a useful behaviour, but I think it may need to be documented.

This would be a major breaking change and I'm not completely sure if I like it myself, but I would like to at least discuss it.

Imagine a hypothetical downstream project that creates locks using names that are only known at runtime. Let's say these names are strings with arbitrary characters. Then some calls to NamedLock::create will inevitably return Err(Error::InvalidCharacter).

This could be avoided if the strings were first encoded so that reserved characters ('\0', '/', and '\\') were transformed to non-reserved characters. The exact encoding scheme is a bikeshed I'm not ready to dive into at the moment, but something like percent-encoding or Base32 would fit the bill.

Pros:

• We could possibly eliminate an Error variant from the public API
• We can guarantee that lock creation can not fail due to invalid bytes
• This can be done without additional allocations (depending on the choice of encoding scheme)

Cons:

• This is a significant breaking change
• The choice of encoding scheme is arbitrary, and every downstream user pays the penalty of that choice

Questions:

• Would it make sense to "fix" NamedLock::create, or to make a new constructor method entirely?
• Would we add an "escape hatch" for the current behavior?
  • If so, should it panic or return an error variant indicating invalid bytes?