Hi all, particularly cedric. I was to do the bindings for the new
ethumb_client_exists() API and got impressed by the number of
problems.
- inconsistent api: void* is the first callback parameter, see
all EFL
- inconsistent api: missing ethumb_CLIENT prefix, like
Ethumb_Exists should be Ethumb_Client_Exists
- strange api: if I have an Ethumb_Exists handle why do I need
all the other parameters? Because Ethumb_Exists is an internal
thing exposed to user! You should return the
Ethumb_Async_Exists_Cb structure (and remove Cb from it)
- memory leak: in _ethumb_client_exists_end() you free the
async->callbacks but nothing frees 'cb' nodes.
- strange behavior: you can create lots of async requests, but
if you cancel one, all of them is cancelled!
- race condition: thread may start and finish before you add the
structure to the hash:
async->thread = ecore_thread_run(...);
eina_hash_direct_add(_exists_request, async->dup, async);
- strange behavior: provided cb is executed even when it was
cancelled
- bad API design: there is no free_cb for exists. If you cancel
it you still get the main cb but this is not clear. This is
bad for bindings.
In my opinion there should be no single-thread per ethumb_client
thing. It's a micro optimization and is useless since most users will
ask just one.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: [email protected]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
