On 2008-01-16 13:12, Dirk Meyer wrote:
> They do similar things. If you use a Thread, it will be started on
> start() and do its job. The ThreadCallback gets a thread name to
> execute it. So when you have 100 functions you want to call in a
> thread, a Thread will spawn 100 threads while a ThreadCallback can
> handle all in one thread or split them into two.
Yes, I see ...
They do seem to me like candidates for consolidation. It seems that
ThreadCallback pretty much does everything that Thread does and more.
I see the point of ThreadCallback, and in fact MainThreadCallback is
just a special case of TheadCallback, isn't it. In the case of the main
thread, the job server (conceptually) runs as part of the main loop,
whereas for non-mainthreads the job-server takes the place of the loop
(for that thread).
If ThreadCallback were callable in the way that all the other Callback
classes are, it could be connected to signals and such, and we could
inherit MainThreadCallback from it. As a first argument, ThreadCallback
could take the name of the thread, or None if a new thread should be
spawned for each call (i.e. there will be no job server).
Each invocation of a ThreadCallback (via __call__) can return its own
InProgress object. Or the caller can connect to the ThreadCallback
object's signal to handle async results for any invocation of that
callback object. This is just what your BackgroundTask class does.
So the ThreadCallback would look something like:
cb = kaa.ThreadCallback('thumbnailer', generate_thumbnail)
cb('file.jpg').connect(handle_thumbnail_done)
(I wonder if it'd be useful to have a convenience function
Signal.connect_thread, in which the callback is wrapped in a
ThreadCallback, so the handler is invoked in the specified thread.)
With this, MainThreadCallback would just be implemented this way:
class MainThreadCallback(ThreadCallback):
def __init__(self, *args, **kwargs):
return super(MainThreadCallback, self).__init__('main', *args,
**kwargs)
Thread would be done away with, since ThreadCallback implements all the
same functionality. So instead of Thread(somefunc).start() you have
ThreadCallback(None, somefunc)()
I know earlier you said that things that start background tasks (either
threads or coroutines) should have an explicit start() method, but I
think that the ability to use these things as Callbacks (where they
behave as callables) is too useful to ignore.
On a related note, I looked at your patch and it looks good, except that
startBackgroundTask doesn't follow our naming convention. The decorator
should be start_background_task()
Jason.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
