On Mon, 19 Nov 2018 at 19:10, Stian Zeljko Vrba
I'd suggest to use fcntl http://man7.org/linux/man-pages/man2/fcntl.2.html which immediately returns an error value if a conflicting lock is attempted to be taken (see under Advisory record locking; F_SETLK). Then you can use a timer to implement retry with exponential back-off or similar.
Well, I could always call flock with LOCK_NB to implement that same strategy. But I would have liked to let the OS tell me instead of keep asking it.
Alternately, I'd take "block all signals" with a grain of salt. You can use signals from the real-time signal range that isn't used by the system, and install a no-op signal handler. It will interrupt blocking operations (cause them to return with EINTR), but I strongly doubt that it'll affect non-blocking operations. (Signals are delivered on return from kernel space to user space and checking for them "too often" would be a performance penalty.)
I was trying to do it "right" and implement a generic asynchronous operation. The client using such an operation could be using any signal, including the real time signals, for its own purpose. But I tried to do all this thinking "If ASIO does it with the blocking getaddrinfo then I can do it with flock". But after looking in more detail at how getaddrinfo in Linux ASIO works: a) There is a single thread, not one per async_resolv. resolving is not done in parallel, each operation is queued one after the other. b) ip::basic_resolver::cancel() doesn't even really try to cancel the current resolving operation, it just cancels any queued one. It only works because getaddrinfo is "blocking"... with an undocumented, implicit, timeout. 'a' is documented, but 'b' really surprised me since the docs say "This function __forces__ the completion of any pending asynchronous operations on the host resolver". Which I guess is not technically wrong, but still... So I'm leaning towards thinking it can not be done "right" with flock (or getaddrinfo, really), the OS interface is simply not good enough.