00:58
ronan__ has joined #pypy
00:58
ronan has quit [Ping timeout: 272 seconds]
01:44
jcea has quit [Ping timeout: 258 seconds]
02:31
mgedmin has joined #pypy
03:04
wleslie has quit [Quit: Lost terminal]
03:05
wleslie has joined #pypy
03:11
andrewsmedina has joined #pypy
04:31
_whitelogger has joined #pypy
06:38
<
mattip >
untranslate pypy/module/_socket/test/test_sock_app.py::test_gethostbyaddr is crashing on win64-py3.6 with the pypy64-2.7 host
07:24
rfgpfeiffer has joined #pypy
07:30
epony has quit [Remote host closed the connection]
07:31
jacob22 has quit [Read error: Connection reset by peer]
07:31
jacob22 has joined #pypy
07:31
epony has joined #pypy
07:39
dddddd has quit [Ping timeout: 240 seconds]
07:50
<
rjarry >
I have a function that allocates a pointer: int sr_connect(foo_t **) and I want to register a destructor
07:50
<
rjarry >
foo_p = ffi.new('foo_t **')
07:50
<
rjarry >
lib.sr_connect(foo_p)
07:51
<
rjarry >
foo = ffi.gc(foo_p[0], lib.sr_disconnect)
07:51
<
rjarry >
however, if there is a signal that causes the program to exit before I register the destructor, it is not called
07:51
<
rjarry >
how can I make sure to register it before calling connect ?
07:52
<
rjarry >
calling gc before connect does not work as it makes a copy
07:53
oberstet has joined #pypy
08:09
<
rjarry >
mattip: not really no
08:10
<
rjarry >
the only solution I found is to block signals before calling connect and unblock them after calling ffi.gc
08:10
<
rjarry >
but I was hoping there is a more elegant solution
09:16
lritter has joined #pypy
09:37
vstinner has quit [Quit: leaving]
09:47
jacob22 has quit [Quit: Konversation terminated!]
10:51
dddddd has joined #pypy
11:27
ronan__ is now known as ronan
11:37
pmp-p has quit [Quit: No Ping reply in 180 seconds.]
11:39
pmp-p has joined #pypy
11:45
pmp-p has quit [Quit: No Ping reply in 180 seconds.]
11:46
pmp-p has joined #pypy
13:37
andrewsmedina has quit []
13:38
andrewsmedina has joined #pypy
13:53
<
lazka >
rjarry, couldn't you block the signal in Python using the signal module?
13:55
andrews has joined #pypy
13:56
<
rjarry >
lazka: block it always ?
13:56
<
rjarry >
depending on the type of callback, you may not know in advance when it will be called
13:56
<
lazka >
also seems racy, what if the signal was already received, you'd still get an exception in the callback, right?
13:57
<
rjarry >
I don't know, I do not have enough knowledge of POSIX signals
13:57
andrews has quit [Client Quit]
13:58
<
lazka >
rjarry, I mean block for the duration of do_stuff_while_under_lock
13:59
<
rjarry >
yes I in that example that would fix this particular issue
13:59
<
rjarry >
but depending on the C libraries, callbacks may be called from threads not created by python
13:59
<
rjarry >
asynchronously
13:59
<
lazka >
I currently handle a similar situation by setting a custom signal handler and checking if it was called afterwards
14:00
<
rjarry >
but as a general matter, it looks to me that since the python callback is called by C code, it cannot propagate any exception
14:00
<
rjarry >
since a signal handler may raise one
14:00
<
rjarry >
I think that python extern callbacks should not be interrupted by signal handlers
14:01
<
rjarry >
I don't know if I'm making sense
14:01
<
rjarry >
because even if you handle the exception, if it is SystemExit, what would you do with it ?
14:01
<
rjarry >
except do some very hackish code
14:02
<
rjarry >
I see no downside in defering the signals to after the callback has returned
14:02
<
rjarry >
except maybe for some race condition I do not forsee
14:04
<
lazka >
I have code that depends on signals in callbacks working.. a C event loop that runs forever and calls into Python
14:04
<
lazka >
(though using cpython api, not cffi)
14:08
<
rjarry >
that is why I suggested to make that optional
14:13
jacob22 has joined #pypy
14:20
jcea has joined #pypy
15:59
andrewsmedina has quit [Quit: Connection closed for inactivity]
17:44
<
ronan >
mattip, mgorny: why did d147d3b422d7 modify rpython/?
17:48
<
mgorny >
ronan: sorry, probably some mercurial magic doing something i didn't anticipate
18:14
lritter has quit [Quit: Leaving]
18:20
mattip_ has joined #pypy
18:22
mattip has quit [Ping timeout: 264 seconds]
19:03
<
ronan >
mgorny: I guess it comes from c8bdc9146f6e then
19:26
rubdos has quit [Ping timeout: 260 seconds]
19:56
jacob22 has quit [Read error: Connection reset by peer]
19:58
jacob22 has joined #pypy
20:12
Dejan has quit [Quit: Leaving]
20:31
Ai9zO5AP has joined #pypy
23:13
Ai9zO5AP has quit [Remote host closed the connection]
23:15
Ai9zO5AP has joined #pypy
23:20
jcea has quit [Remote host closed the connection]
23:20
jcea has joined #pypy
23:24
jcea has quit [Client Quit]
23:25
jcea has joined #pypy
23:28
jcea has quit [Client Quit]
23:28
jcea has joined #pypy