On Thu, Jul 2, 2009 at 4:04 PM, Jean-Paul Calderone wrote:
> On Thu, 2 Jul 2009 15:47:48 -0700, "Gregory P. Smith"
>> If you want signals to actually be handled in a timely manner, its
>> best to leave the main thread of the program alone as a signal
>> handling thread that just spends its time in
On Thu, 2 Jul 2009 15:47:48 -0700, "Gregory P. Smith" wrote:
On Mon, Jun 29, 2009 at 2:28 PM, "Martin v. Löwis" wrote:
AFAIK, ignoring EINTR doesn't preclude the calling of signal handlers.
This is my understanding as well - so I don't think Python actually
"swallows" the signal.
A great ex
On Mon, Jun 29, 2009 at 2:28 PM, "Martin v. Löwis" wrote:
>> AFAIK, ignoring EINTR doesn't preclude the calling of signal handlers.
>
> This is my understanding as well - so I don't think Python actually
> "swallows" the signal.
>
>> A great example is reading from a socket. Whether or not it can b
> AFAIK, ignoring EINTR doesn't preclude the calling of signal handlers.
This is my understanding as well - so I don't think Python actually
"swallows" the signal.
> A great example is reading from a socket. Whether or not it can be
> interrupted depends on the platform, so catching Ctrl+C often
I'll do my best to try and explain/contribute, but please feel free to
correct anything I get wrong.
I believe the "swallowing" he's referring to is the ignoring of errno
EINTR. I don't think that's the correct place to handle signals to
begin with- why not just use the signal module to deal with
Martin v. Löwis wrote:
Can you please explain what you mean by "swallowing"?
The signals don't get through when acquiring the lock.
What is the sequence of actions triggering the case you are talking
about, what happens, and what do you expect to happen instead?
Easiest way is to create a Queue
Martin v. Löwis wrote:
> Can you please explain what you mean by "swallowing"?
The signals don't get through when acquiring the lock.
> What is the sequence of actions triggering the case you are talking
> about, what happens, and what do you expect to happen instead?
Create a Lock object, call .a
> Now to my real question. I have noticed that PyThread_acquire_lock
> swallows all signals with pthread using sems. Looking at the source code
> it appears that this is intended, but I cannot see the reason for that.
> It seems the pthread sem implementation is the only one doing so. Can
> any of
Hello.
As this is my first post I will try to introduce myself as requested in
the welcome email. If you aren't interested in my person, just continue
reading at the next paragraph. I'm a student from Vienna/Austria. I
attend what would match high school in the United States. I have been
writi
