Greg Ewing schrieb:
> Correct me if I'm wrong, but what I got from the OP
> was that the current method does
Ok, I'm correcting you: This is not what the current
method does:
>
>if (is_tripped) {
> for each signal {
>if the signal has occurred, call its handler
> }
> i
On 1/27/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Why not?
>
> Correct me if I'm wrong, but what I got from the OP
> was that the current method does
>
>if (is_tripped) {
> for each signal {
>if the signal has occurred, call its handler
> }
> is_tripped = 0;
>}
>
Martin v. Löwis wrote:
> Greg Ewing schrieb:
>
>>>Please
>>>try to come up with a patch (e.g. by putting a while(is_tripped) loop
>>>around the for loop).
>>
>>That isn't going to fix it.
>
> Why not?
Correct me if I'm wrong, but what I got from the OP
was that the current method does
if (i
I apologise for going off-topic, but this is an explanation of why
I said that signal handling is not reliable. The only relevance to
Python is that Python should avoid relying on signals if possible,
and try to be a little defensive if not. Signals will USUALLY do
what is expected, but not alway
Greg Ewing schrieb:
>> Please
>> try to come up with a patch (e.g. by putting a while(is_tripped) loop
>> around the for loop).
>
> That isn't going to fix it.
Why not?
> What's needed is to somehow
> atomically test and clear is_tripped at the beginning.
How would that help? The case in quest
Nick Maclaren wrote:
> This one looks like an oversight in Python code, and so is a bug,
> but it is important to note that signals do NOT work reliably under
> any Unix or Microsoft system.
That's a rather pessimistic way of putting it. In my
experience, signals in Unix mostly do what they're
me
Martin v. Löwis wrote:
> Please
> try to come up with a patch (e.g. by putting a while(is_tripped) loop
> around the for loop).
That isn't going to fix it. What's needed is to somehow
atomically test and clear is_tripped at the beginning.
You can put a while loop around it as well if you want,
bu
On 1/24/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Gustavo Carneiro schrieb:
>What about http://www.python.org/sf/1564547 ? It tries to solve a
> different problem, but I think it also fixes this one; at least as much
> as possible with the braindead unix signal programming interface.
On 1/24/07, Ulisses Furquim <[EMAIL PROTECTED]> wrote:
> On 1/24/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I agree it's a bug, and I agree with your proposed analysis. Please
> > try to come up with a patch (e.g. by putting a while(is_tripped) loop
> > around the for loop). Also make sur
Gustavo Carneiro schrieb:
>What about http://www.python.org/sf/1564547 ? It tries to solve a
> different problem, but I think it also fixes this one; at least as much
> as possible with the braindead unix signal programming interface...
I'm sceptical. It is way too much code for me to review,
On 1/24/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Ulisses Furquim schrieb:
> I've read some threads about signals in the archives and I was under
> the impression signals should work reliably on single-threaded
> applications. Am I right? I've thought about a way to fix this, but I
> don
On 1/24/07, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> Obviously, Unix and Microsoft systems depend on signals, so you
> can't simply regard them as hopelessly broken, but you can't assume
> that they are RELIABLE. All code should be designed to cope with
> the case of signals getting lost, if at
On 1/24/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I agree it's a bug, and I agree with your proposed analysis. Please
> try to come up with a patch (e.g. by putting a while(is_tripped) loop
> around the for loop). Also make sure you include test case.
Ok. I was discussing this problem wit
On Tue, Jan 23, 2007, Ulisses Furquim wrote:
>
> I've read some threads about signals in the archives and I was under
> the impression signals should work reliably on single-threaded
> applications. Am I right? I've thought about a way to fix this, but I
> don't know what is the current plan for s
Ulisses Furquim schrieb:
> I've read some threads about signals in the archives and I was under
> the impression signals should work reliably on single-threaded
> applications. Am I right? I've thought about a way to fix this, but I
> don't know what is the current plan for signals support in pyth
On Tue, Jan 23, 2007, Ulisses Furquim wrote:
>
> I've read some threads about signals in the archives and I was under
> the impression signals should work reliably on single-threaded
> applications. Am I right? I've thought about a way to fix this, but I
> don't know what is the current plan for s
Hi,
I'm aware of the problems with signals in a multithreaded application,
but I was using signals in a single-threaded application and noticed
something that seemed wrong. Some signals were apparently being lost,
but when another signal came in the python handler for that "lost"
signal was being
17 matches
Mail list logo
