Hi,
Mattia Barbon wrote:
Octavian Rasnita wrote:
It is also very important to use threads in a app that uses a GUI, and I
don't know how easy is to use threads under Python, but under Perl is
not
very easy, and the apps that use threads consume very many resources.
I agree. Some form of concurrency is extremely important for GUI apps.
I can't tell how easy or hard it is to use threads in Python, but it
slightly bothers me that they can't use multiple CPU cores. Not that
this is a problem for many applications...
AFAIK threads in Python "just work": it does not take much time or RAM
to create a thread (unlike Perl), you do not need to be aware that each
thread has its own interpreter and that the easiest/safest way to pass
data between threads is by serializing/deserializing it, and that when a
thread is spawned all your objects will be cloned (and destructors will
run twice!).
All in all, I believe that most of the time threads are used for
IO-bound stuff, and there Python GIL does not make much difference.
I agree. But most of the time is not all the time. Having both options
available would be ideal. Now, I have no clue whether the preemptive
coros would be at all ithread safe.
Just yesterday I had a chat with Arthur Bergman who (AFAIK) wrote most
of the ithreads code. He had pretty good arguments for ithreads in his
environment: Little shared data, large load on the CPUs.
By the way: He also said he'd practically always use ithreads in the
following way: Create one ithread very, very early and use it to create
more from there. This may solve part of the memory overhead problem that
we usually see from ithreads.
Unfortunately, Wx.pm currently needs to be loaded before
threads/threads::shared. Is there a way around that?
Cheers,
Steffen