>> Looking at your function list, my other concern is that you are calling
>> Python API without holding the GIL, IIUC. In particular, you are
>> accessing _PyThreadState_Current, which may not point to the current
>> thread if the current thread has released the GIL.
>
> Ah? Where does _PyThreadS
Le lundi 20 décembre 2010 à 02:05 +0100, "Martin v. Löwis" a écrit :
> The problem is that merely being POSIX compliant would not be enough
> to allow calling a function in a signal handler. Instead, the function
> *also* needs to be async-signal safe.
Yes, this issue was fixed in an older version
On 19/12/2010 23:02, Victor Stinner wrote:
Le samedi 18 décembre 2010 à 08:50 -0500, James Y Knight a écrit :
I think instead of calling abort() to kill the process, you should:
- install the signal handler with SA_NODEFER|SA_RESETHAND (or if sigaction is
not present, explicitly reset the actio
> What? Is it a myth or does Python really support multiple interpreters
> in the same process? How is it possible? Who uses this?
[Not sure if you are joking]
There is certainly some support for multiple interpreters in Python; the
most prominent user of this feature is mod_python.
Regards,
Mar
> Functions used by the fault handler:
> - write()
> - PyUnicode_Check()
> - PyFrame_GetLineNumber()
> - DebugBreak() (Windows, in debug mode, only)
> - abort()
> - (macro) PyUnicode_GET_SIZE() and PyUnicode_AS_UNICODE()
> - PyUnicode_Check(), PyFrame_Check()
> - PyFrame_GetLineNumber()
>
On Sun, 19 Dec 2010 18:54:55 -0500
Terry Reedy wrote:
> On 12/19/2010 1:41 PM, Guido van Rossum wrote:
> > On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote:
>
> >> This could be nicely resolved by renaming the arguments "a" and "b",
> >> and having the diff display "a, b". It's quite natura
Le lundi 20 décembre 2010 à 00:02 +0100, Victor Stinner a écrit :
> Another possible approach is to restore the previous handler in the
> fault handler, and don't call abort(). The fault should occur again, and
> so the previous signal handler will be called.
I implemented this simple approach in
Le 18/12/2010 16:33, Oleg Broytman a écrit :
>This is quite a known problem, not specific to Python. Locale
> settings are global for a process, and this is one of the thousands
> reasons why locale is considered so horrible.
>ICU is perhaps the only way around the problem.
Babel rocks: ht
On 12/19/2010 1:41 PM, Guido van Rossum wrote:
On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote:
This could be nicely resolved by renaming the arguments "a" and "b",
and having the diff display "a, b". It's quite natural (both the diff
ordering and the arguments ordering), and they are c
Le samedi 18 décembre 2010 à 08:50 -0500, James Y Knight a écrit :
> I think instead of calling abort() to kill the process, you should:
> - install the signal handler with SA_NODEFER|SA_RESETHAND (or if sigaction is
> not present, explicitly reset the action to SIG_DFL and unblock first thing
>
On Sun, 19 Dec 2010 23:37:58 +0100
Victor Stinner wrote:
> Le dimanche 19 décembre 2010 à 20:20 +0100, Antoine Pitrou a écrit :
> > Can you clarify why you think those signal handlers fall into that
> > description? After all, SIGINT, SIGILL and friends only get triggered in
> > catastrophic condi
Le dimanche 19 décembre 2010 à 20:20 +0100, Antoine Pitrou a écrit :
> Can you clarify why you think those signal handlers fall into that
> description? After all, SIGINT, SIGILL and friends only get triggered in
> catastrophic conditions.
SIGSEGV, not SIGINT
Victor
_
On 12/18/2010 8:50 AM, James Y Knight wrote:
> I think instead of calling abort() to kill the process, you should:
> - install the signal handler with SA_NODEFER|SA_RESETHAND (or if
> sigaction is not present, explicitly reset the action to SIG_DFL and
> unblock first thing upon entering the handle
Le samedi 18 décembre 2010 à 13:55 -0500, Alexander Belopolsky a écrit :
> I am -1 on the feature as written. I would be -0 if it did not
> install signal handlers by default and even better was implemented in
> a separate module, not in core.
I think that the feature is useless if it is disabled
Le samedi 18 décembre 2010 à 17:23 +0100, Georg Brandl a écrit :
> Well, without a closer I assume that for some crashes it's just not
> possible anymore for the Python interpreter to even print out the
> traceback?
The worst case occurs if the frame objects are corrupted, eg. if the
filename of a
Le dimanche 19 décembre 2010 à 19:53 +0100, "Martin v. Löwis" a écrit :
> There should be at least one reviewer with an established track record
> of being interested/knowledgable in the POSIX APIs and cross-platform
> aspects of it.
Functions used by the fault handler:
- write()
- PyUnicode_Che
On Sun, Dec 19, 2010 at 2:20 PM, Antoine Pitrou wrote:
..
>> There should be at least one reviewer with an established track record
>> of being interested/knowledgable in the POSIX APIs and cross-platform
>> aspects of it.
>> As I said, any of the Twisted guys would qualify.
>
> James Knight alrea
On Dec 19, 2010, at 10:41 AM, Guido van Rossum wrote:
> On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote:
>> On Sat, 18 Dec 2010 20:23:49 -0800
>> Guido van Rossum wrote:
>>> I may be unique, but I fear there is no great answer. On the one hand
>>> I almost always code it as e.g. assertEqu
Le dimanche 19 décembre 2010 à 19:53 +0100, "Martin v. Löwis" a écrit :
> >> This is also what I think. Installing a signal handler is a fairly
> >> drastic action, and I don't think the code has been sufficiently
> >> reviewed yet.
> >
> > How much more review should it receive?
>
> There shoul
>> This is also what I think. Installing a signal handler is a fairly
>> drastic action, and I don't think the code has been sufficiently
>> reviewed yet.
>
> How much more review should it receive?
There should be at least one reviewer with an established track record
of being interested/knowled
> I suppose there could be some sort of locale database. A downloadable,
> up-to-date copy of the database could be maintained on the Python
> website.
I think you are quite underestimating the implementation effort.
So -0 on your original proposal until such a thing actually exists.
Regards,
Mar
Le dimanche 19 décembre 2010 à 10:41 -0800, Guido van Rossum a écrit :
> On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote:
> > On Sat, 18 Dec 2010 20:23:49 -0800
> > Guido van Rossum wrote:
> >> I may be unique, but I fear there is no great answer. On the one hand
> >> I almost always code i
On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote:
> On Sat, 18 Dec 2010 20:23:49 -0800
> Guido van Rossum wrote:
>> I may be unique, but I fear there is no great answer. On the one hand
>> I almost always code it as e.g. assertEqual(actual, expected), which
>> matches my preference for e.g.
Hello Senthil,
> +raise TypeError("data should be byte-like object\
Should be "bytes-like".
> +request.add_unredirected_header(
> +'Content-length', '%d' % len(mv) * mv.itemsize)
There is an operator precedence problem here:
>>>
On Sat, 18 Dec 2010 20:23:49 -0800
Guido van Rossum wrote:
> I may be unique, but I fear there is no great answer. On the one hand
> I almost always code it as e.g. assertEqual(actual, expected), which
> matches my preference for e.g. "if x == 5:" rather than "if 5 == x:".
> On the other hand in t
On Sat, Dec 18, 2010 at 06:21:24PM -0500, Terry Reedy wrote:
> On 12/18/2010 10:33 AM, Oleg Broytman wrote:
>
>> This is quite a known problem, not specific to Python. Locale
>> settings are global for a process, and this is one of the thousands
>> reasons why locale is considered so horrible.
26 matches
Mail list logo
