freenode/#sbcl - IRC Chatlog
Search
11:48:24
flip214
minion: memo for stassats: Please push your unwind-inspector into a contrib or so, slime could make use of that information
12:54:04
phoe
If I read the docstrings at https://github.com/sbcl/sbcl/blob/e98378ca004ef6d101b384f6c3130f24b7a1bc1f/src/code/serve-event.lisp#L215 correctly, then the call (SB-SYS:WAIT-UNTIL-FD-USABLE 7 :INPUT NIL NIL) has no timeout (will hang indefinitely).
12:54:34
phoe
I don't think that's the correct behavior in case of READ-CHAR-NO-HANG that shouldn't hang at all.
13:11:17
phoe
I think that this might be the race-condition issue that's been kicking me for the last two days.
13:21:12
minion
stassats, memo from flip214: Please push your unwind-inspector into a contrib or so, slime could make use of that information
13:23:05
pfdietz
I tried to reduce it past what the pruner could do, but you apply a broader range of simplifications, I think.
13:25:22
stassats
it looks like another instance of reoptimization not being triggered by changes that don't involve data flow
13:26:27
pfdietz
Well, whatever it is, any fix should wait until after freeze, especially if it's not a recent regression.
13:27:33
stassats
your particular form does not fail it inserts type checks and the old code reoptimizes the whole thing in that case
13:29:15
stassats
but there's more question, it stops optimizing, yet the IR1 is consistent at that point
13:30:12
pfdietz
I wonder if it would be useful to write a random ir1 generator, to better exercise the later code.
13:32:02
stassats
if we do inconsistent things to the IR but there's nobody to hear it, does it make a sound?
13:32:46
pfdietz
Understood. The issue is that bugs in later code can be latent because the earlier passes don't produce inputs that would stimulate them. Changes to the earlier passes, even if correct in themselves, can then activate those bugs.
13:40:00
stassats
from the error you can see that the problem is that an IF comes to the same block, which is not well-formed IR1, at least for cmovp conversion
13:42:03
stassats
before DCE the IF points to two different blocks, but they end up dead, removed, their successor substituted
13:43:02
stassats
(if m 10 10) will be transformed into 10, so M doesn't need to computed aside from any side effects (including type checks)
13:44:59
stassats
but IF is already in a state to be optimized, even before doing dead code elimination
14:01:33
phoe
Yep, this is the file descriptor issue that I was battling yesterday. On a different machine and a slightly older SBCL version I have managed to get a backtrace.
14:02:10
phoe
I've been trying to reduce that issue to a reproducible test case, but damn, it isn't trivial... I might need a day or two more.
14:03:19
phoe
Basically, I'm opening a socket and trying to read from it from one thread while closing it from another thread. And something wonky happens along the way.
14:09:17
phoe
is it somewhere in that backtrace I provided? it doesn't seem like it can be at stack frame 0 because wait-until-fd-usable doesn't seem to call serve-event
14:10:40
phoe
...I like the naming convention of serve-event, sub-serve event and sub-sub-serve-event
14:20:07
phoe
my bug is definitely a race condition - if I sleep for a millisecond between closing the socket and trying to read from it, the hanging is gone.
14:39:41
phoe
I'm not killing the socket that the thread is operating on - I'm kllling that socket's other end
14:40:17
phoe
if A and B are a pair of connections bound of each other, then the thread is operating on A and I'm closing B - and the hang happens in that case
14:41:17
phoe
yep - I actually took a while to look at my code and make sure that I'm not killing streams cross-threadedly
14:42:46
phoe
I might be issuing READ-CHAR-NO-HANG from thread B and reading from the same socket in thread A
15:04:01
stassats
trying to see how far it goes, and whether i can remove maybe-delete-exit from physenv-analyze altogether
15:05:24
phoe
Is it permitted to one thread to write to a stream while the other is reading from it?
15:17:23
stassats
was going to push to github, but if it's easier for you to use sbcl's git i can do that too
16:40:38
phoe
minion: memo for stassats: anyway, I am curious. When READ-CHAR-NO-HANG is called, WAIT-UNTIL-FD-USABLE is nonetheless called without any timeout. How does it work so it doesn't block nonetheless?
16:40:57
phoe
minion: memo for stassats: I mean, in the backtrace that I've posted here and on launchpad.
17:51:28
minion
stassats, memo from phoe: anyway, I am curious. When READ-CHAR-NO-HANG is called, WAIT-UNTIL-FD-USABLE is nonetheless called without any timeout. How does it work so it doesn't block nonetheless?
17:51:28
minion
stassats, memo from phoe: I mean, in the backtrace that I've posted here and on launchpad.
17:54:44
phoe
stassats: hm, I kind of get it... there's a hidden READ-CHAR call somewhere between READ-CHAR-NO-HANG and WAIT-UNTIL-FD-USABLE?