On Thu, Jan 24, 2013 at 02:37:27PM +0400, Konstantin Osipov <kostja.osi...@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 --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev