">

(original) (raw)

Ok,

I‘ve been busy with other stuff, but I‘m almost finished with a patch to submit as an alternative.

cProfile.enable() will then take an „allthreads“ argument, which when enabled, will set the profiler state on all threads �\_currently\_ running.

 

Now, I only realized this late, but \_currently\_ is really not good enough.� In order to do this properly, you want to also profile threads that are created during the session.

 

For this reason, Maybe I was a bit rash invalidating this. �Anyway, keep your eyes trained on issue 9609 where I‘ll hopefully put my patch in real soon now.

 

K

 

From: python-dev-bounces+kristjan=ccpgames.com@python.org \[mailto:python-dev-bounces+kristjan=ccpgames.com@python.org\] On Behalf Of GrosBedo
Sent: Thursday, September 09, 2010 5:10
To: python-dev@python.org
Subject: Re: \[Python-Dev\] cProfile and threads

 

Hello,

Ive just stumbled accross your changes Krisvale, and from your last reply, I can see that you invalidated your changes :

I just realized that this is probably a redundant change.
lang=EN-US>We have C apis to get all the Thread states in an interpreter state (I didn't even know there was such a thing as multiple interpreter states, but there!)<o:p>
This is the PyInterpreterState_ThreadHead() api et al.
>From C, all that is missing is a SetTrace api that takes a thread state.
 
>From python, the threading module provides access to all Thread objects, and each of those has a settrace/setprofile method.
 
To turn on global tracing from cProfile, all that is needed is to iterate over all the Thread objects.

Setting this to invalid, since there already are APIs to do this, at least from .py code.

 Could you please provide more explanations, or even an example ? Because it seems that you're the only one on earth to finally find a way to multithread the cProfiler...