Jason Tackaberry wrote: > 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).
Yes, conceptually they are the same, but the implentation is a very
different. 'main' needs a completly different JobServer. Right now we
have MainThreadCallback is a simple class, we would have to greate a
MainJobServer to inherit MainThreadCallback from JobServer. This is
writing code without the API feeling different.
> So the ThreadCallback would look something like:
>
> cb = kaa.ThreadCallback('thumbnailer', generate_thumbnail)
> cb('file.jpg').connect(handle_thumbnail_done)
This would break some code, but I guess we are at a point where it
does not matter anymore.
> (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.)
Yes
> 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.
But we want to keep Timer with a start function, right?
> 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()
Yes, that was on purpose to check if you notice it :)
I had to do some Java coding at work, they always use camel
case. Looking at JavaScript and even Python modules like xml or
twisted, camal case is what they use. So maybe we could start breaking
things completly and use camel case. I personally don't like variables
like 'in_progress = InProgress', it looks bad to me (that is why I
name the variable async most of the cases). inProgress = InProgress
looks better IMHO.
Dischi
--
Who the fuck is "General Failure", and why is he reading my disk?
pgpeGk0MGmfpN.pgp
Description: PGP signature
------------------------------------------------------------------------- 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
