Jason Tackaberry wrote: > Dirk Meyer wrote: >> see that threading doesn't slow down things. Second (very strange): >> when no thread is running, but threading itself is active, it is >> slower. But still, not much. > > The GIL isn't initialized until a thread is created (or a C module > explicitly initializes it, as in the case of kaa-xine). So in common, > non-thread cases, the GIL isn't used at all, so that overhead is > avoided. Once a thread has started, the GIL is initialized and so it > must be acquired/released at certain points.
And since Freevo uses threads for blocking IO (e.g. rom drive
checking), we have GIL but most of the time we have no thread.
> Anyway, your test probably isn't very good, but I think it's good enough
> for testing the impact threads have in programs like Freevo.
I know it's a bad test, but it is enough to see if threads or a major
speed problem.
> So Python threads are good for getting around blocking operations, but
> not very good for parallizing tasks on SMP boxes. I ran your test on my
> SMP box (dual P3 800) and got these results:
>
> Normal operation: 142.627851009 secs
> Threading operation: 144.94809103 secs
> Normal operation with threading: 137.823442936 secs
>
> All the work in your test is in Python space, so the GIL prevents any
> useful parallization from happening.
Yes. For kaa.vfs (and also kaa.thumb) I was thinking about a process
and using your IPC. Both are host local and should communicate over an
unix socket. I have no idea how gconfd or the kde stuff is working,
but I think of the following:
- When the server is needed, it will auto start. I don't want to start
the process myself.
- When there is already a process running, use it without starting
another
- A process without clients will exit after x seconds
I guess we have to look at the source of gconf how to do that.
Dischi
--
"Real stupidity beats artificial intelligence every time."
-- Bursar 1 - Hex 0 (Terry Pratchett, Hogfather)
pgpOCW0dDIX2j.pgp
Description: PGP signature
