Steffen Mueller wrote:
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.
OTOH only having the solution that has benefits in a minority of cases
and having everybody else jump through fire hoops in order to use
threads is very, very suboptimal.
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.
I do not know his specific requirements, I'd just say that at my
previous job if the task called for threads, Python was used, and Perl
was not considered an option (and, frankly, for very good reasons):
- memory occupation
- creating new threads is slow
- because some key modules are not thread-safe (DBI for example,
discourages use of threads in production!)
And, unfortunately, I have heard many more people raising similar
points than I heard people saying that ithreads were the right tool for
their job.
Besides, the workaround above will only work it if the background
task does not require many modules.
Unfortunately, Wx.pm currently needs to be loaded before
threads/threads::shared. Is there a way around that?
Wx.pm does
our %stash : shared;
SetStash( \%stash );
and if threads/threads::shared are not loaded this is a no-op; just
moving this to a separate module will also require some XS work, because
the SetStash call must be XS and must directly or indirectly set a
variable visible to Wx::PlThreadEvent. I think your best bet is moving
Wx::PlThreadEvent to a separate XS module that does not depend on wxPerl.
It is probably easier (and will benefit more people) changing Wx to
create subroutines/packages lazily when required, reducing startup time
and memory occupation.
Mattia
