libeio: discrepancy between the manual and the code

[Marc Lehmann]

On Thu, Jan 24, 2013 at 02:37:27PM +0400, Konstantin Osipov <kostja.osipov at gmail.com> wrote:
> If thread 1 decides to cancel the task, it needs a way to find
> out that thread 2 is no longer using struct task *, so that it can
> be freed.

Thread programming is full of synchronisation problems, and this should be
easy to solve.

Keep in mind that the complication arises in code outside libeio (your
eio_custom callback), and you can introduce lots of problems that are hard
to solve that way. So your example isn't valid for libeio, because the
problem simply doesn't exist in libeio.

Libeio shouldn't accumulate bloat to help solve problems that simply don't
exist when it's used properly.

Even if you do find a valid example (which I doubt), then you can always
solve it by using a custom eio_destroy hook.

> The only way to reliably find this out is to wait until done_cb
> is invoked.

Or use a mutex, which should be the obvious way to protect shared data
- note that you need to use a mutex anyway to avoid data races. If you
don't, your code is buggy regardless of whether libeio calls the callback
or not, as libeio makes no guarantees for data outside of its influence.

I think you often have some kind of tunnel vision - you see one way of
possibly solving things, and then insist it is the only or best way even
when alternatives are available or the way you think is best isn't even
working properly.

These synchronisaton problems are really very basic thread programming
problems, and in no way specific to libeio.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\