Re: [Boost-users] Making an ASIO asynchronous operation from flock()

Subject: Re: [Boost-users] Making an ASIO asynchronous operation from flock()
From: Cristian Morales Vega (cristian_at_[hidden])
Date: 2018-11-20 10:12:11

On Mon, 19 Nov 2018 at 19:10, Stian Zeljko Vrba <vrba_at_[hidden]> wrote:
> 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.