On Mon, Sep 26, 2016 at 4:28 AM, Jean-Philippe André <j...@videolan.org> wrote: > But still, despite its predictable behaviour, cancellation is hard to > handle properly. The guys from Android chose not to support it and use > alternative solutions like select instead of just read. > > So I still wonder if adding optional cancellation support is a good idea or > not. I think we should make and use APIs (network in particular) that don't > require cancellation.
well, my goal with this work was twofold: - see how much simpler my own code would be if cancellation was used, as opposed to a pure-async-via-callbacks would be. It showed to be much simpler and easier, thus validates my point on why our users want to use that (many users don't get how to rewrite the algorithms and prefer to use threads due that). - allow external users doing threads to be better supported by EFL so it's not solely about internal development, its also about the library being used by users expecting to be able to do that. In VLC likely you do not have this, its solely for internal consumption. In Android you also don't have that as everything is pushed to upper layers, like java. Only those adventurous doing NDK feel the pain. -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
