[issue27483] Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c

[Maciej Fijalkowski]

Maciej Fijalkowski added the comment:

On windows the profiler runs in a separate thread and pauses/restarts other 
threads (hence the requirements are slightly different). HEAD_LOCK etc. are def 
not async-signal safe, but it's not an issue on linux

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27483] Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c

[STINNER Victor]

STINNER Victor added the comment:

Is the profiler running in the same process than the profiled application?

Vmprof uses a signal handler, right? HEAD_LOCK is a mutex, acquire a mutex
is not async-signal safe :-( Is it an issue?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27483] Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c

[Maciej Fijalkowski]

New submission from Maciej Fijalkowski:

Hi

The use case here is for C-based statistical profilers. When running vmprof on 
linux/os x, you can get the current thread state from 
PyThreadState_GetUnchecked or a similar solution. However, on windows you need 
to walk all the interpreter state, for which there is an API. However that API 
is only ever used with locks (HEAD_LOCK/HEAD_UNLOCK), which are not exposed, 
which turns API mostly useless.

--
messages: 270188
nosy: fijall, haypo
priority: normal
severity: normal
status: open
title: Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com