00:32:28 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 00:57:36 <|3b|> anyway to send a particular thread into ldb without involving gc or world locks? 01:00:39 don't know about threads, but (define-alien-routine ("ldb_monitor" ldb-monitor) void) (ldb-monitor) 01:01:18 <|3b|> yeah, found that part, but trying to send it through interrupt-thread doesn't seem to be working out 01:09:57 <|3b|> or maybe i was just doing the interrupt stuff wrong and i could have sent it to normal debugger 01:12:52 <|3b|> ... or maybe that only works if it happens to get the timing right to not actually have the info i want on the stack anymore (or something) 01:32:27 -!- loke [~elias@bb115-66-87-235.singnet.com.sg] has quit [Ping timeout: 258 seconds] 01:32:59 -!- slyrus_ [~chatzilla@173-228-44-88.dsl.static.sonic.net] has quit [Read error: Operation timed out] 01:39:05 loke [~elias@bb115-66-87-235.singnet.com.sg] has joined #sbcl 01:55:35 -!- hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has quit [Quit: Leaving...] 02:14:51 esden [~esden@repl.esden.net] has joined #sbcl 02:47:04 -!- stassats [~stassats@wikipedia/stassats] has quit [Read error: Operation timed out] 04:41:43 scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has joined #sbcl 05:16:18 hakkum [~hakkum@c-67-181-176-186.hsd1.ca.comcast.net] has joined #sbcl 06:15:35 flip214 [~marek@86.59.100.100] has joined #sbcl 06:15:35 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 06:15:35 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 06:43:15 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 06:43:53 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 07:04:06 cpc26 [cpc26@pilot.trilug.org] has joined #sbcl 07:13:14 -!- hakkum [~hakkum@c-67-181-176-186.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 07:15:33 -!- Quadrescence [~Quad@unaffiliated/quadrescence] has quit [Ping timeout: 250 seconds] 07:20:34 Kryztof [~user@csrhodes.plus.com] has joined #sbcl 07:20:34 -!- ChanServ has set mode +o Kryztof 07:38:09 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 07:38:09 -!- ChanServ has set mode +o nikodemus 07:39:22 morning 08:12:20 morning! 08:56:43 i just realized: now i can affort ECLM :) 08:56:51 afford, even 09:04:36 "affront" is only a levenshtein distance away, too ;) 09:04:45 ok, two 09:07:02 uh,oh. my paypal receiving limit has been exceeded. now i need to find an utilities bill to scan and send or something, i guess... 09:07:08 ha 09:07:19 nice problem to have :) 09:20:50 -!- daimrod [~daimrod@sbrk.org] has quit [Quit: reboot] 09:31:48 daimrod [~daimrod@sbrk.org] has joined #sbcl 09:50:44 added the widget to sbcl.org -- left out explanatory text as i could not make it non-ugly 09:51:05 -!- ASau [~user@95-28-79-252.broadband.corbina.ru] has quit [Quit: off] 09:51:10 does that look ok, or should i try to squeeze in something about the context? 09:55:05 I don't have a problem with it 09:55:37 ok 09:56:06 bah, making (map '%string-3 'identity '(#\f #\o #\o)) is harder than it should be. (Alternative way of looking at that: fixing mild bugs in TYPEXPAND) 10:00:34 attila_lendvai [~attila_le@catv-89-132-188-166.catv.broadband.hu] has joined #sbcl 10:00:34 -!- attila_lendvai [~attila_le@catv-89-132-188-166.catv.broadband.hu] has quit [Changing host] 10:00:34 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:04:09 hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has joined #sbcl 10:15:19 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 258 seconds] 10:16:03 -!- scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has quit [Remote host closed the connection] 10:17:17 scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has joined #sbcl 10:41:48 -!- hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has quit [Quit: Leaving...] 10:42:37 hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has joined #sbcl 11:17:50 -!- jiacobucci [~jiacobucc@gw-asdl.ae.gatech.edu] has quit [Ping timeout: 252 seconds] 11:27:24 stassats [~stassats@wikipedia/stassats] has joined #sbcl 11:29:00 -!- hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has quit [Quit: Leaving...] 11:52:36 -!- flip214 [~marek@unaffiliated/flip214] has quit [Quit: Leaving] 11:58:08 -!- Vivitron` [~user@pool-71-174-61-33.bstnma.fios.verizon.net] has left #sbcl 11:59:22 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 11:59:22 -!- ChanServ has set mode +o nikodemus 12:27:39 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 12:29:20 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 13:45:05 -!- DGASAU [~user@91.218.144.129] has quit [Remote host closed the connection] 13:46:32 DGASAU [~user@91.218.144.129] has joined #sbcl 14:05:42 -!- loke [~elias@bb115-66-87-235.singnet.com.sg] has quit [Quit: Leaving] 14:28:46 homie [~levgue@xdsl-78-35-151-65.netcologne.de] has joined #sbcl 15:22:00 <|3b|> can a thread holding or waiting on a lock be interrupted and told to do something some other lock (gc in particular)? 15:22:03 -!- slyrus [~chatzilla@99-28-163-38.lightspeed.miamfl.sbcglobal.net] has quit [Remote host closed the connection] 15:23:24 it could happen. 15:23:42 especially holding a lock. 15:23:44 Why? 15:24:05 *|3b|* suspects it does happen, and confuses the deadlock detection 15:24:59 can you sketch your suspicion? 15:25:30 oh wow. I'd forgotten how nice 5 minute builds are. 15:26:17 <|3b|> thread A waiting on lock help by B, both interrupted for something GC related and try to grab GC lock, some other thread gets it first, A and B check for deadlocks and one gets confused due to the locks held/waited before it was interrupted 15:26:29 <|3b|> (or something like that, haven't thought it out fully yet) 15:26:54 so.. A waits on B 15:27:05 gc magic happens, A grab the GC lock, and B waits on it? 15:27:24 yeah, that would look like a cycle. 15:30:31 *|3b|* suspects a similar problem in the timer test deadlock cycle as well, haven't looked at that one at all though 15:42:06 homie` [~levgue@xdsl-78-35-137-135.netcologne.de] has joined #sbcl 15:42:58 -!- homie` [~levgue@xdsl-78-35-137-135.netcologne.de] has quit [Remote host closed the connection] 15:44:51 -!- homie [~levgue@xdsl-78-35-151-65.netcologne.de] has quit [Ping timeout: 276 seconds] 15:45:15 homie` [~levgue@78.35.137.135] has joined #sbcl 16:01:22 -!- homie` [~levgue@78.35.137.135] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 16:03:39 homie [~levgue@xdsl-78-35-137-135.netcologne.de] has joined #sbcl 16:17:08 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Remote host closed the connection] 16:40:21 |3b|: /something/ like that is what i think is happening. i thought about the case when i wrote the code, but i must have gotten it wrong 17:13:46 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 17:37:27 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 17:37:27 -!- ChanServ has set mode +o nikodemus 18:01:36 slyrus_ [~chatzilla@173-228-44-88.dsl.static.sonic.net] has joined #sbcl 18:19:46 -!- slyrus_ [~chatzilla@173-228-44-88.dsl.static.sonic.net] has quit [Ping timeout: 260 seconds] 18:25:22 check out these two lines of sbcl disassembly ^-^ 18:25:23 ; 7F1: L1: 840500000021 TEST AL, [#x21000000] ; 7F7: L2: 840500000021 TEST AL, [#x21000000] 18:25:47 the only reason it emits the same instruction twice as far as I can tell is for the two jump labels. 18:26:50 sbcl doesn't have a peep-hole optimizer 18:27:02 oh! 18:27:02 someone worked on one, but i don't know what's the status 18:27:11 that explains these oddities 18:27:50 no. 18:27:58 nevermind that the TEST AL [#x2100000] instruction still makes no sense as to the purpose. 18:28:08 they're safe points 18:28:22 ok I have seen mention of gc safepoints 18:28:23 the GC can change the protection at that address to stop all the threads 18:28:25 but how do they work? 18:28:34 OH! 18:29:05 there's very naive logic to insert these safe points because they're really cheap. 18:29:10 that makes sense 18:29:37 well it makes sense to me now why they even exist ;) 18:29:57 I mean just looking at the disassembly output does not make it all that clear why AL is compared to that memory address ;) 18:30:06 it helps to know that you're using the win32-threads branch. 18:30:09 especially as the result of the test is never used ;) 18:30:15 pkhoung yep 18:30:30 little netbook I'm using to develop on atm 18:31:26 and really pkhoung the windows port is aweful stable 18:32:01 I'm running a multithreaded application using it with no issues at all. 18:32:29 but I'm into OS devel and low level coding as a side hobby 18:32:52 I find messing with that stuff fun for some odd reason, to the point of having read the intel and arm manuals 18:33:10 I need to try the arm sbcl port out sometime ^-^ 18:35:49 though pkhoung you should know on an intel atom or similar cpu with a low instruction fetch rate, multiple TEST AL ... instructions can cause fetch stalls, especially if the compiler puts them in some inner loop. 18:36:23 I'll pay attention to that once the safepoint work is merged in. 18:36:57 Atom has a fetch rate of 8 bytes per clock 18:37:31 so if you string enough of those the cpu won't be able to do anything else until it retires those ops 18:37:46 of course none of this tested, I just know about the issue from reading manuals for fun 18:38:41 I also know the sandy bridge from intel has a microop cache which can at times make loop unrolling a _bad_ thing to do if unrolling the loop causes the code to overflow the microp cache. 18:39:15 that has been the case on various intel uarchs since the P4 18:39:20 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 18:39:43 but the loop caches tend to be so small that it rarely matters... not that SBCL does any unrolling. 18:41:08 pkhoung yea I know from playing with it :) Just saying 18:41:43 lisper: you're spelling pkhuong's name wrong! 18:41:58 thanks 18:41:59 oh I am 18:42:00 needs more tab 18:42:11 and by micro op cache i mean sandy bridge caches the uops, not the undecoded higher level opcodes. 18:42:21 which is new AFAIK. 18:42:29 nope. 18:43:07 ok then :) 18:56:21 slyrus_ [~chatzilla@173-228-44-88.dsl.static.sonic.net] has joined #sbcl 19:09:03 -!- lisper [18d1340b@gateway/web/freenode/ip.24.209.52.11] has quit [Quit: Page closed] 19:35:32 *|3b|* wonders if thread-waiting-for should be cleared while a thread is interrupted 19:39:25 I don't think there's a correct way to do this... 19:39:47 I guess the interrupted body of code should be considered like a distinct thread 19:40:37 <|3b|> can't just set it to nil before running the interruption and reset it on unwind-protect? 19:41:20 you probably want to detect self-deadlocks on non-recursive locks. 19:41:25 (i.e. sane locks ;) 19:41:40 <|3b|> not sure what you mean 19:42:03 thread acquires M, thread is interrupted; interrupt handler waits on M. 19:42:22 <|3b|> presumably failing to detect some deadlocks is better than detecting some that aren't there in either case though 19:42:44 <|3b|> hmm 19:43:09 <|3b|> i don't think the change i'm suggesting would affect that 19:43:33 <|3b|> if i understand correctly, this slot is just for threads actively waiting, so it wouldn't be set for the thread in that case 19:43:38 right only touching waiting for wouldn. 19:44:11 yup. the interrupt handler should clear that flag. 19:44:23 the interrupted thread will set it again when it re-attempts to acquire the mutex. 19:47:09 except that might not work with nikodemus's upcoming fair spinlocks. 19:47:54 naw, interrupted threads should cancel their tickets. 20:24:48 -!- slyrus_ [~chatzilla@173-228-44-88.dsl.static.sonic.net] has quit [Ping timeout: 276 seconds] 20:35:43 ASau [~user@95-28-79-252.broadband.corbina.ru] has joined #sbcl 20:40:17 hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has joined #sbcl 20:43:42 stassats [~stassats@wikipedia/stassats] has joined #sbcl 20:44:52 <|3b|> does this test case look valid? http://paste.lisp.org/+2NOI 20:49:40 slyrus_ [~chatzilla@173-228-44-88.dsl.static.sonic.net] has joined #sbcl 20:52:36 -!- slyrus_ [~chatzilla@173-228-44-88.dsl.static.sonic.net] has quit [Remote host closed the connection] 20:57:15 -!- hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has quit [Quit: Linkinus - http://linkinus.com] 21:00:54 hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has joined #sbcl 21:22:07 <|3b|> i guess clearing thread-waiting-for will miss deadlocks against the code running before the interruption, so that might not be completely right either... not sure how to detect that though 21:23:17 <|3b|> maybe have a stack there, and help locks can store the value when they were acquired, so deadlock detection can stop checking there? 21:23:54 <|3b|> (all this assuming nobody hold a lock, waits on another, then releases the held lock in an interruption) 21:30:04 If we only care a little about performance, and MCAS makes interrupt safety trivial. 21:41:45 |3b|: that test case looks good to me. 21:42:09 And I'm actually convinced that clearing waiting-for before handling the interrupt is fine. 21:44:23 <|3b|> fine as in wouldn't miss deadlocks involving the interrupted code, or just fine as in more correct than current code? 21:44:38 wouldn't miss deadlocks either 21:45:54 *|3b|* supposes the right thing to do would be to write a test case and make sure either way :) 21:46:09 I don't see how a test case can ensure anything :p 21:46:50 <|3b|> well, either it errors, or deadlocks without an error 21:47:24 prxq [~mommer@mnhm-5f75fec2.pool.mediaWays.net] has joined #sbcl 21:47:38 <|3b|> admittedly, doesn't ensure there aren't variants that behave differently 21:55:47 <|3b|> when is sb-sys::invoke-interruption used vs sb-thread::run-interruption? 21:56:25 I don't understand interrupt stuff (which might be the reason why I want to move to lock-free/wait-free protocols so much ;) 21:56:35 <|3b|> or maybe sb-unix:invoke-interruption 21:59:53 <|3b|> ah, maybe invoke calls run, and it is getting TCOd out of the stack or something 22:01:05 <|3b|> yeah, that seems to be the case 22:27:50 -!- prxq [~mommer@mnhm-5f75fec2.pool.mediaWays.net] has quit [Quit: Leaving] 22:41:20 -!- homie [~levgue@xdsl-78-35-137-135.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 22:55:54 |3b|: In the not-entirely up-to-date version of the code base I'm working with, INVOKE-INTERRUPTION is about interrupts == signals with handlers established by ENABLE-INTERRUPT. Whereas RUN-INTERRUPTION is about "thread interruptions" (in the sense of INTERRUPT-THREAD). 22:59:03 Easily confused because the INTERRUPT-THREAD machinery also uses an interrupt (!), namely SIGPIPE to arrange for the "interruption" (argh!) to be called. 23:04:23 <|3b|> lichtblau: yeah, it was the TCO that tricked me 23:07:23 Can someone confirm that the lock at the end of is interrupt/signal safe? 23:09:00 I'm almost starting to believe that events and CAS are easier to work with correctly than mutex/condvar. 23:10:57 -!- hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has quit [Quit: Leaving...]