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;
>}
>
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
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
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
