On Sun Feb 08 2015 at 12:21:36 AM Victor Stinner
wrote:
>
> Le 8 févr. 2015 05:39, "Gregory P. Smith" a écrit :
> > From there, in your signal handler you must try to acquire the newly
> exposed keymutex and (...)
>
> Stop! Acquiring a lock in a signal handler is just a crazy idea. It's very
> f
This is exactly how signals are implemented in Python :-)
Victor
Le lundi 9 février 2015, Robert Collins a
écrit :
> On 9 February 2015 at 09:11, Maciej Fijalkowski > wrote:
> > Hi Francis
> >
> > Feel free to steal most of vmprof code, it should generally work
> > without requiring to patch c
On 9 February 2015 at 09:11, Maciej Fijalkowski wrote:
> Hi Francis
>
> Feel free to steal most of vmprof code, it should generally work
> without requiring to patch cpython (python 3 patches appreciated :-).
> As far as timer goes - it seems not to be going anywhere, I would
> rather use a backgr
2015-02-08 4:01 GMT-05:00 Maciej Fijalkowski :
> I'm working on vmprof (github.com/vmprof/vmprof-python) which works
> for both cpython and pypy (pypy has special support, cpython is
> patched on-the fly)
This looks interesting. I'm working on a profiler that is similar, but not
based on timer.
Hi Francis
Feel free to steal most of vmprof code, it should generally work
without requiring to patch cpython (python 3 patches appreciated :-).
As far as timer goes - it seems not to be going anywhere, I would
rather use a background thread or something
On Sun, Feb 8, 2015 at 10:03 PM, Francis
I'm working on vmprof (github.com/vmprof/vmprof-python) which works
for both cpython and pypy (pypy has special support, cpython is
patched on-the fly)
On Sun, Feb 8, 2015 at 6:39 AM, Gregory P. Smith wrote:
> To get at the Python thread state from a signal handler (using 2.7 as a
> reference her
Le 8 févr. 2015 05:39, "Gregory P. Smith" a écrit :
> From there, in your signal handler you must try to acquire the newly
exposed keymutex and (...)
Stop! Acquiring a lock in a signal handler is just a crazy idea. It's very
far from an async signal-safe function.
> So until those are fixed (hoo
Le 7 févr. 2015 22:34, "Greg Ewing" a écrit :
with --shared)
> You might be able to use Py_AddPendingCall to schedule
> what you want done outside the context of the signal
> handler.
I don't how it could work. You have to increment the reference counting,
but also maybe increment references to o
To get at the Python thread state from a signal handler (using 2.7 as a
reference here; but i don't believe 3.4 has changed this part much) you
need to modify the interpreter to expose pystate.c's "autoTLSkey" and
thread.c's "struct key" as well as "keyhead" and "keymutex".
>From there, in your si
Maciej Fijalkowski wrote:
However, you can't access thread
locals from signal handlers (since in some cases it mallocs, thread
locals are built lazily if you're inside the .so, e.g. if python is
built with --shared)
You might be able to use Py_AddPendingCall to schedule
what you want done outsi
On 02/06/2015 11:48 PM, Francis Giraldeau wrote:
> 2015-02-06 6:04 GMT-05:00 Armin Rigo:
>
> Hi,
>
> On 6 February 2015 at 08:24, Maciej Fijalkowski mailto:fij...@gmail.com>> wrote:
> > I don't think it's safe to assume f_code is properly filled by the
> > time you might read it, d
On Sat, Feb 7, 2015 at 12:48 AM, Francis Giraldeau
wrote:
> 2015-02-06 6:04 GMT-05:00 Armin Rigo :
>
>> Hi,
>>
>> On 6 February 2015 at 08:24, Maciej Fijalkowski wrote:
>> > I don't think it's safe to assume f_code is properly filled by the
>> > time you might read it, depending a bit where you f
2015-02-06 6:04 GMT-05:00 Armin Rigo :
> Hi,
>
> On 6 February 2015 at 08:24, Maciej Fijalkowski wrote:
> > I don't think it's safe to assume f_code is properly filled by the
> > time you might read it, depending a bit where you find the frame
> > object. Are you sure it's not full of garbage?
Hi,
On 6 February 2015 at 08:24, Maciej Fijalkowski wrote:
> I don't think it's safe to assume f_code is properly filled by the
> time you might read it, depending a bit where you find the frame
> object. Are you sure it's not full of garbage?
Yes, before discussing how to do the utf8 decoding,
On 06.02.2015 00:27, Francis Giraldeau wrote:
> I need to access frame members from within a signal handler for tracing
> purpose. My first attempt to access co_filename was like this (omitting
> error checking):
>
> PyFrameObject *frame = PyEval_GetFrame();
> PyObject *ob = PyUnicode_AsUTF8Strin
Hi,
2015-02-06 0:27 GMT+01:00 Francis Giraldeau :
> I need to access frame members from within a signal handler for tracing
> purpose.
IMO you have a big technical or design issue here. Accessing Python
internals in a signal handler is not reliable. A signal can occur
anytime, between two instruc
Hi Francis
I don't think it's safe to assume f_code is properly filled by the
time you might read it, depending a bit where you find the frame
object. Are you sure it's not full of garbage?
Besides, are you writing a profiler, or what exactly are you doing?
On Fri, Feb 6, 2015 at 1:27 AM, Franci
On Thu Feb 05 2015 at 4:36:30 PM Francis Giraldeau <
francis.girald...@gmail.com> wrote:
> I need to access frame members from within a signal handler for tracing
> purpose. My first attempt to access co_filename was like this (omitting
> error checking):
>
> PyFrameObject *frame = PyEval_GetFram
On Fri, Feb 6, 2015 at 10:27 AM, Francis Giraldeau
wrote:
> Instead, I access members directly:
> char *str = PyUnicode_DATA(frame->f_code->co_filename);
> size_t len = PyUnicode_GET_DATA_SIZE(frame->f_code->co_filename);
>
> Is it safe to assume that unicode objects co_filename and co_name are al
I need to access frame members from within a signal handler for tracing
purpose. My first attempt to access co_filename was like this (omitting
error checking):
PyFrameObject *frame = PyEval_GetFrame();
PyObject *ob = PyUnicode_AsUTF8String(frame->f_code->co_filename)
char *str = PyBytes_AsString
20 matches
Mail list logo
