freenode/#sbcl - IRC Chatlog
Search
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?
22:49:30
aeth
In LOOP if I have := foo where foo is some conditional that is always false on the 0th iteration, then it warns about deleting unreachable code because it handles the 0th separately from the rest
22:50:02
aeth
I can avoid that unreachable code message by having := the-true-part-of-foo :then foo but then of course that duplicates some code unnecessarily