I'm afraid Kristjan left CCP some time ago, and may not subscribe to this
list any more.
Steve Holden
On Tue, Sep 25, 2018 at 4:23 PM Antoine Pitrou wrote:
> On Tue, 25 Sep 2018 09:09:26 -0600
> Eric Snow wrote:
> > On Tue, Sep 25, 2018 at 1:45 AM Victor Stinner
> wrote:
> > > Please don't r
On Tue, Sep 25, 2018 at 9:30 AM Gregory P. Smith wrote:
> We can't change the API of the main thread being where signal handlers are
> executed by default.
>
> If a signal handler raised an exception in a daemon thread, the process would
> not die when it goes uncaught (ie: why KeyboardInterrupt w
On Mon, Sep 24, 2018 at 1:20 PM Eric Snow
wrote:
> On Mon, Sep 24, 2018 at 11:14 AM Yury Selivanov
> wrote:
> > On Fri, Sep 21, 2018 at 7:04 PM Eric Snow
> wrote:
> > > 1. Why do we restrict calls to signal.signal() to the main thread?
> > > 2. Why must signal handlers run in the main thread?
>
On Tue, 25 Sep 2018 09:09:26 -0600
Eric Snow wrote:
> On Tue, Sep 25, 2018 at 1:45 AM Victor Stinner wrote:
> > Please don't rely on this ugly API. *By design*, Py_AddPendingCall()
> > tries 100 times to acquire the lock: if it fails to acquire the lock,
> > it does notthing... your callback is i
On Tue, Sep 25, 2018 at 1:45 AM Victor Stinner wrote:
> Please don't rely on this ugly API. *By design*, Py_AddPendingCall()
> tries 100 times to acquire the lock: if it fails to acquire the lock,
> it does notthing... your callback is ignored...
Yeah, there are issues with pending calls as imple
Please don't rely on this ugly API. *By design*, Py_AddPendingCall()
tries 100 times to acquire the lock: if it fails to acquire the lock,
it does notthing... your callback is ignored...
By the way, recently, we had to fix yet another bug in signal
handling. A new function has been added:
void
_P
On Mon, Sep 24, 2018 at 3:10 PM Yury Selivanov wrote:
> On Mon, Sep 24, 2018 at 4:19 PM Eric Snow wrote:
> > This matters to me because I'd like to use "pending" calls for
> > subinterpreters, which means dealing with signals *in*
> > Py_MakePendingCalls() is problematic. Pulling the
> > PyErr_C
On Mon, Sep 24, 2018 at 4:19 PM Eric Snow wrote:
[..]
> Is there a good place where this weirdness is documented?
I'll need to look through uvloop & libuv commit log to remember that;
will try to find time tonight/tomorrow.
[..]
> This matters to me because I'd like to use "pending" calls for
>
On Mon, Sep 24, 2018 at 11:14 AM Yury Selivanov wrote:
> On Fri, Sep 21, 2018 at 7:04 PM Eric Snow wrote:
> > 1. Why do we restrict calls to signal.signal() to the main thread?
> > 2. Why must signal handlers run in the main thread?
> > 3. Why does signal handling operate via the "pending calls"
On Fri, Sep 21, 2018 at 6:10 PM, Victor Stinner wrote:
>
> Moreover, you can get the signal while you don't hold the GIL :-)
Note that, in Windows, SIGINT and SIGBREAK are implemented in the C
runtime and linked to the corresponding console control events in a
console application, such as python.
On Fri, Sep 21, 2018 at 7:04 PM Eric Snow wrote:
>
> Hi all,
>
> I've got a pretty good sense of how signal handling works in the
> runtime (i.e. via a dance with the eval loop), but still have some
> questions:
>
> 1. Why do we restrict calls to signal.signal() to the main thread?
> 2. Why must s
On Fri, Sep 21, 2018 at 5:11 PM Victor Stinner wrote:
> Le sam. 22 sept. 2018 à 01:05, Eric Snow a
> écrit :
> > 3. Why does signal handling operate via the "pending calls" machinery
> > and not distinctly?
>
> Signals can be received anytime, between two instructions at the
> machine code level
On Sat, 22 Sep 2018 at 09:14, Victor Stinner wrote:
>
> Le sam. 22 sept. 2018 à 01:05, Eric Snow a
> écrit :
> > 3. Why does signal handling operate via the "pending calls" machinery
> > and not distinctly?
>
> Signals can be received anytime, between two instructions at the
> machine code level
Le sam. 22 sept. 2018 à 01:05, Eric Snow a écrit :
> 3. Why does signal handling operate via the "pending calls" machinery
> and not distinctly?
Signals can be received anytime, between two instructions at the
machine code level. But the Python code base is rarely reentrant.
Moreover, you can get
Hi all,
I've got a pretty good sense of how signal handling works in the
runtime (i.e. via a dance with the eval loop), but still have some
questions:
1. Why do we restrict calls to signal.signal() to the main thread?
2. Why must signal handlers run in the main thread?
3. Why does signal handling
15 matches
Mail list logo
