00:00:35 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Ping timeout: 272 seconds] 00:06:09 pkhuong, Using 0.55 to build on OS 10.8, there are two threading errors in the tests in 0.57, but the latest builds and tests fine 00:07:22 Quadrescence: I have a tagged 1.0.57...did it build fine for you? 00:08:05 hargettp, I built from the source release of 0.57. Is that what you're asking? 00:08:18 yes, that's what I did...no issues for you? 00:08:32 There were two errors in the tests 00:08:45 But the build went okay 00:08:57 Hmmm....not 100% sure mine did....do you build with threading on or off? 00:09:23 I assume on. (I'm only a novice at the build process.) 00:09:34 I just used the make shell script. 00:09:59 ah. you have to explicitly enable threading on Mac OS X; it's not on by default...I usually turn it on, but I am finding that when I do, my .57 doesn't finish building 00:10:12 hargettp, I can test now 00:10:47 Quadrescence, cool; would be good if we can get a reproducible scenario...even if it's just "it doesn't build" lol 00:11:43 booklet [~booklet@unaffiliated/quadrescence] has joined #sbcl 00:11:54 Okay, let's give this a shot. 00:11:54 booklet, memo from pkhuong: it ought to be done, and I prefer it to happen in dedicated commits. 00:11:55 booklet, memo from pkhuong: (re source cleanups) 00:12:22 hargettp: Do you want me to test 0.57 or the latest? 00:12:54 booklet: are you on Mac OS X Mountain Lion? .57 worked (and built) fine for me on Lion, but not on Mountain Lion 00:13:10 Yes I am on Mountain Lion. 00:13:31 Yah, sure, thx; if you can try a build with threading enabled that would be great....my build doesn't finish 00:13:47 have to turn threading off to a get a usable binary 00:16:50 hargettp, if it matters, i'm going to build 0.57 with the latest stuff. 00:17:15 The stuff on its way to 0.58? Sure, that's cool; if it works, I'll update my repo :) 00:17:23 yes 00:17:49 so fast http://www.youtube.com/watch?v=_zzQiot-x7Y 00:17:58 wbooze [~wbooze@xdsl-78-35-135-10.netcologne.de] has joined #sbcl 00:19:25 WARNING! Some of the contrib modules did not build successfully or pass 00:19:25 their self-tests. Failed contribs:" 00:19:25 sb-concurrency 00:19:47 booklet: bingo--yep, that's what I get. If i leave threading disabled, the build ends fine 00:20:22 that was true for me too (modulo the failed tests) 00:20:36 I'll try building the latest with threading now. 00:22:49 uh...wasn't that the error from a build with threading ON? 00:23:16 No, I mean, Ill build the latest sbcl sources with threading on. 00:23:23 That was building 0.57 with threading on. 00:23:30 ah cool 00:24:35 The same happens with the latest sources 00:25:48 shoot...wonder if Quadrescence will have same issue :( 00:25:56 that is me 00:25:58 :) 00:26:01 oh hello! :) 00:26:12 / Running /Users/quad/Source/Foreign/sbcl/tests/threads.pure.lisp 00:26:12 ::: Running ATOMIC-UPDATE 00:26:12 fatal error encountered in SBCL pid 18133(tid 41964544): 00:26:12 mach_port_allocate_name failed with return_code 5 00:26:25 oh that's cool.... 00:27:12 lemme see if the Apple Developer docs have anything useful.... 00:28:08 that's unknown error, iirc. 00:28:15 yeesh 00:29:05 right, KERN_FAILURE (: 00:29:13 08:41:40 heffalumpen: #define KERN_FAILURE 5... Got to love descriptive error codes. 00:31:15 "The function returns KERN_SUCCESS if the call succeeded, KERN_INVALID_TASK if task was invalid, KERN_INVALID_VALUE if right was invalid or name was MACH_PORT_NULL or MACH_PORT_DEAD, KERN_NAME_EXISTS if name was already in use for a port right and KERN_RESOURCE_SHORTAGE if the kernel ran out of memory." 00:32:12 so your kern_invalid_value was 5! 00:32:18 :) 00:32:56 now lookup what that means on your OS! 00:32:58 lol 00:33:06 #define KERN_FAILURE 5 00:33:08 :) 00:33:15 what Quadrescence posted :) 00:33:44 mach_port_allocate yes 00:34:48 there is a call to that in src/runtime/darwin-os.c 00:37:19 mach_thread_init has a call to allocate_name 00:37:37 yeah... I don't know if we could go for pure posix on darwin now 00:38:21 hargettp: can you try replacing current_mach_task with mach_task_self() ? 00:38:50 sure, I can give it a whirl...give mea few 00:38:52 and rebuild/retry? 00:39:42 sure. You could slam.sh and rebuild the contribs by hand, but if you're on a decent machine, what's 4 extra minutes? (: 00:40:15 I'll rebuild all :) 00:40:23 pkhuong: Just in mach_thread_init? 00:40:38 how about in the call to mach_port_insert_right? 00:40:47 yeah, where? I see both symbols all over 00:41:26 hargettp: well there's an assignment to current_mach_test right below the first two funcalls 00:41:47 darwin-os.c:110. Let's try and play wackamole later. 00:41:56 current_mach_thread is something else. 00:42:20 when does the runtime get built in the build process?> 00:42:34 and I may not have same sources...still on 1.0.57 :) 00:42:42 booklet: make-target-2 00:42:55 I am happy to apply a fix if there are ideas :0 00:42:59 pkhuong: i assume that is not in the first 10 seconds 00:43:03 hargettp: the first argument to mach_port_allocate_name. 00:43:27 ah yes ty...I see it now 00:43:29 booklet: no, it's the short 5-30 second phase that only runs cc near the end. 00:43:36 okay good 00:43:45 Well I'm building the latest sources with that change. 00:44:03 me too; in emacs this time, so should be faster than OS X terminal :) 00:44:41 hargettp: screen really helps there, especially with logging enabled. 00:44:41 alright, building with threading ON using the tagged .57 source 00:45:05 pkhuong: will try to sort that out sometime ty :) 00:45:10 the failure still occurs 00:45:20 booklet: same failure? 00:45:33 same build warning, running the tests now 00:46:00 yes, tests too: mach_port_allocate_name failed with return_code 5 00:47:16 hey...I see an assignment to current_mach_task in only 1 place in the file...but is that call made *before* these other functions are called? Any chance the value is not always initialized properly (and thus set to MACH_PORT_NULL)? 00:48:33 hargettp: we'd see the failure on earlier versions. 00:49:09 I'm not a Mach programmer...but could the semantics of MACH_PORT_NULL changed? 00:49:46 pretty sure the commit that stopped using mach_task_self all over the place was right, but you could add an assert just to make sure. 00:51:25 -!- chturne [~chturne@host86-148-233-236.range86-148.btcentralplus.com] has quit [Quit: Leaving] 00:54:12 hargettp: oh god... I think I know what's going on. 00:54:22 pkhuong: ? 00:55:15 Does threaded 32 bit work fine? 00:55:26 dunno but I could build and find out 00:55:38 For the record, the value it's getting is NOT MACH_PORT_NULL 00:55:49 booklet: k 00:56:08 we're punning addresses into unsigned int. That was actually semi-supported on mach, pre x86-64. 00:56:30 uh oh 00:56:33 pkhuong: :O 00:57:01 suddenly I don't care if the 32-bit build works... ;) 00:57:08 that sounds like a v plausible answer 00:57:23 but seriously...if you do think a 32-bit would be interesting to see, I can do it :) 00:59:06 The punning only goes one way, AFAICT, but maybe the documentation lies and we get KERN_FAILURE on collisions. 01:02:02 pkhuong: where's the punning happening? 01:02:32 THREAD_STRUCT_TO_EXCEPTION_PORT 01:04:03 ah k 01:07:53 hargettp: if it also fails on x86, I can just give up (: 01:08:07 pkhuong: shoot! :) 01:08:27 well, any of this useful to add to that bug that's out there on launchpad? :) 01:09:01 It would probably be a good idea, particularly if x86 works fine. 01:09:15 how does one make an x86 build? 01:09:19 ^^ 01:09:26 do I just disable the :x86-64 feature? 01:09:29 and rebuild? 01:09:38 SBCL_ARCH=x86 ./make.sh 01:09:43 lol sweet 01:10:05 i'm giving it a whirl 01:11:03 yup, me 2 01:13:01 got the build warning 01:13:14 the same one we've been seeing with x64? 01:13:18 yes 01:13:20 about sb-concurrency? 01:13:23 shucks 01:13:24 correct 01:13:36 same error in tests 01:13:38 guessing I'll the see the same in another 2-3 mins :) 01:16:53 can SBCL be built with clang instead? how? 01:17:04 would that even have anything to do with it? 01:17:28 seeing as OS 10.8 was built entirely with clang, AFAIK 01:18:05 booklet: could be. I *think* Apple is switching more stuff to LLVM-based stuff, and less on actual gcc 01:18:20 hargettp: that is definitely what they're doing 01:18:23 for example: ls -lh `which gcc` yields /usr/bin/gcc -> llvm-gcc-4.2 01:18:48 oh yeah, that's right 01:19:06 this rings a bell...just can't recall what bell.... 01:19:49 can you lisppaste the build warning? 01:21:21 my builds end with http://paste.lisp.org/+2SVO 01:21:43 yes, that's because the tests failed in sb-concurrency. 01:22:32 http://paste.lisp.org/display/130741 01:24:05 oddly, I may have slightly diff errors for x86 http://paste.lisp.org/+2SVP/1 01:24:17 or I have no idea what I'm looking for (v plausible ;) ) 01:25:00 hargettp: I did not get that. But this was with the latest SBCL 01:25:03 hargettp: quad pasted from sbcl's test suite 01:25:11 ah lol 01:25:22 mine was just from the build output itself 01:25:29 is it possible we're getting recycled thread addresses and the port isn't dead yet somehow? 01:25:45 slyrus: maybe.. 01:26:01 I'm thinking of just going for an additional slot in the thread struct 01:26:30 if that works, we can try and think about going back to our punsterly ways. 01:32:15 slyrus: no, should be fine. 01:32:58 -!- booklet [~booklet@unaffiliated/quadrescence] has quit [Quit: booklet] 01:33:22 pkhuong, what struct would you add a slot to? 01:38:59 the thread struct. 01:39:58 it's created during genesis; quite the hack. 01:54:13 Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has joined #sbcl 01:56:44 -!- Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has quit [Read error: Connection reset by peer] 02:01:59 pkhuong: and use mach_port_allocate instead? 02:11:21 _travis_ [~nonya@nc-71-52-232-124.dhcp.embarqhsd.net] has joined #sbcl 02:12:42 slyrus: I was gonna go with an arbitary counter, but that sounds smarter 02:24:12 booklet [~booklet@unaffiliated/quadrescence] has joined #sbcl 02:37:32 pkhuong: are you doing it? 02:39:00 Kind of occupied preparing for local politics, unfortunately. It's high on my stack, but nothing more. 02:39:22 ok, I might take a stab at it tonight if I'm not too jet-lagged 02:40:15 Functions like %allocate-bignum purportedly get translated somewhere else, since their DEFUN definition is essentially (defun f (x) (f x)). Where's the actual definition/implementation of this function/functions like these? 02:41:44 booklet: when M-. doesn't return anything useful, the VOPs are usually defined implicitly in compiler/generic/objdef.lisp 02:44:48 pkhuong: thanks, exactly what I wanted 02:47:48 #!+alpha (padding) 02:47:49 :) 03:06:48 -!- _travis_ [~nonya@nc-71-52-232-124.dhcp.embarqhsd.net] has quit [Quit: Nettalk6 - www.ntalk.de] 03:17:18 (defun nth-but-with-sane-arg-order (list index) 03:17:18 (nth index list)) 03:17:22 hah 03:18:08 PuercoPop [~PuercoPop@190.41.173.174] has joined #sbcl 03:18:18 -!- PuercoPop [~PuercoPop@190.41.173.174] has left #sbcl 03:24:52 psilord1 [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 03:27:41 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Ping timeout: 272 seconds] 03:29:07 -!- booklet [~booklet@unaffiliated/quadrescence] has quit [Quit: booklet] 03:38:00 -!- hargettp [~hargettp@pool-71-184-181-94.bstnma.east.verizon.net] has quit [Quit: Leaving...] 03:52:56 Phoodus [~foo@ip72-223-116-248.ph.ph.cox.net] has joined #sbcl 04:03:47 sdemarre [~serge@91.176.48.154] has joined #sbcl 07:24:25 -!- kanru [~kanru@209.118.182.194] has quit [Remote host closed the connection] 08:59:23 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 09:03:50 lcc [~user@unaffiliated/lcc] has joined #sbcl 09:03:59 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Ping timeout: 272 seconds] 09:04:13 -!- lcc [~user@unaffiliated/lcc] has left #sbcl 09:18:06 rbarraud [~rbarraud@222-155-139-54.jetstream.xtra.co.nz] has joined #sbcl 09:29:14 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 09:35:14 tcr1 [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 10:10:57 -!- tcr1 [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Quit: Leaving.] 10:27:47 hargettp [~hargettp@pool-71-174-136-63.bstnma.east.verizon.net] has joined #sbcl 10:32:19 -!- rbarraud [~rbarraud@222-155-139-54.jetstream.xtra.co.nz] has quit [Read error: Operation timed out] 11:54:30 -!- wbooze [~wbooze@xdsl-78-35-135-10.netcologne.de] has quit [Read error: Operation timed out] 12:07:16 wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has joined #sbcl 12:13:48 -!- wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has quit [Quit: Client Quit] 12:16:29 wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has joined #sbcl 12:27:06 -!- sdemarre [~serge@91.176.48.154] has quit [Ping timeout: 264 seconds] 13:05:10 -!- wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has quit [Remote host closed the connection] 13:05:55 wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has joined #sbcl 13:18:09 is nikodemus on summer holiday? 13:24:41 slyrus: I think so. 13:25:43 ok. morning pkhuong. 13:26:46 thank you 13:29:03 do you think we should try to get the 10.8 changes in during the freeze? 13:29:33 slyrus: oh cool! is this that issue being unable to build .57 or later on 10.8? :) 13:29:43 slyrus: does it work? 13:30:03 hargettp: wait, what? 1.0.56 builds and works fine on 10.8? 13:30:11 no, not yet, but assuming we get a fix, I think it would be nice to get it in the next release even though were "frozen". 13:30:42 let's try for an rc, if we get it (: 13:30:52 pkhuong: ? no, i was referring to the issue Quadrescence you and I were discussing last night....can't build multi-threaded 1.0.57 (or HEAD) on 10.8 13:31:22 pkhuong: re 1.0.56 - I have no idea if anything earlier than 1.0.57 builds 10.8....never tried 13:31:25 :) 13:31:44 hargettp: right, but you wrote .57 or later. Do earlier releases work? If so, we'd have a different and likely simpler issue. 13:32:15 I'm guessing those were single-threaded 13:32:17 pkhuong: ah, yes, was only clarifying the boundaries as I've observed them...how far back to do you think I should try? 13:32:45 slyrus probably has better educated guesses 13:43:15 I'm wondering if we need to move to the 64-bit mach exception handling routines. I hate to have two code paths for this stuff, but it might be the case that we need to use the newer APIs (for both x86 and x86-64) on 10.8. 13:45:48 is it naive to hope that we could instead move back to posixly routines now that we've deprecated 10.3 and earlier? 13:48:42 I think those are even worse. nikodemus spent a lot of time on this stuff in the last year or so, IIRC. 13:49:59 is OS X not well-behaved wrt the POSIX APIs? 13:50:25 somewhere around broken. 13:50:30 oy 14:03:21 pkhuong: at one point you could build without #!+mach-exception-handler and you would get the posix stuff only, but that was a long time ago 14:08:21 -!- huangjs [~huangjs@190.8.100.83] has quit [Read error: Connection reset by peer] 14:29:16 well, that was really useful: we have macros to go thread struct <-> port, but, AFAICT, the only place we go port -> doesn't use the macro 14:32:21 oh, where's that? 14:32:28 catch_exception_raise 14:32:37 ah, that's probably the thing I forgot 14:32:44 I'm working on cleaning/refactoring this stuff 14:33:44 but, yes, if we decouple the thread and port, how are we going to recover the thread associated with a port? walk all_threads? 14:34:40 -!- wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has quit [Quit: none] 14:35:04 it's for occasions like these that I sometimes wish we'd move the runtime to C++ 14:35:29 wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has joined #sbcl 14:35:51 let's start that way and bsearch or something if it ends up working. 14:37:07 it does seem that using the address of the thread struct as the port is a recipe for failure 14:37:27 it can't work: port names are 32 bit. 14:37:34 right 14:37:40 we've just been extremely lucky 14:41:52 well, we could hack it up: our thread structs could be aligned to very many bits (they are on the order of multi MB, after all :). 15:02:00 it's been a long time since I've built with sb-show on 15:02:21 i'm worried abou the locking protocol 15:02:42 jpw 15:02:45 how's that? 15:05:27 if we're going to walk all_threads in the mach exception handler, we have to lock, and then it gets hairy 15:06:04 we're not already locked? 15:08:22 only mach_exception_lock 15:15:26 so didn't the same problem exist before, but we were just ignoring it by using the thread address as the port name? 15:15:45 yeah, we ere luck. 15:15:48 *were lucky. 15:18:15 seems ok to grab all_threads_lock. It's never acquired before any other lock. 15:21:14 just passed sb-concurrency tests! 15:24:42 all contribs built. now to test x86. 15:27:19 jsnell: around? 15:28:01 chturne [~chturne@host86-148-233-236.range86-148.btcentralplus.com] has joined #sbcl 15:28:58 pkhuong: what do we do if it's locked? 15:29:40 ok.. hack: we can bump THREAD_ALIGNMENT_BYTES to 16K 15:29:58 how does that help? 15:30:27 yay. x86 passes. 15:31:31 soryr, 64 K. That way we can shift the lower 16 bits out 15:31:46 still, what does that do for us? 15:31:46 and amd64 won't use more than 48 bits of address space for a while 15:33:23 <|3b|> do you need to actually align them? if they are never closer than 64k, just grabbing bits 16-48 should always be different anyway 15:34:02 we need to go both ways 15:34:12 <|3b|> ah, right 15:46:42 pkhuong: https://github.com/slyrus/sbcl/tree/mach-thread-cleanup-2 15:48:42 there's a for_all_thread macro, fwiw (: 15:49:12 oh, right 15:49:30 well, where else do we use mach port names? 15:50:11 Nowhere, I think. good. 15:50:19 I think that's correct 15:51:09 yeah, we need a lock in catch_exception_raise. 15:51:51 and to do the same thing in x86-64-darwin-os.c 15:56:14 ok, convince me we can't ever handle exceptions for dying threads? 15:56:32 what do you mean be we need a lock? we're not going to call pthread_mutex_lock from inside catch_exception_raise are we? 15:56:57 what happens if a thread is unlinked while we walk all_threads? 15:57:20 unlinked is fine, actually, it's de-allocations I'm worried about 16:07:49 slyrus: fwiw, we're already calling pthread_mutex_lock there. 16:08:12 yes, I saw that 16:08:52 rebuilding with all_threads lock now 16:09:01 I notice that the x86 version doesn't do as much locking 16:13:28 yes, so what do we do if threads are already locked? 16:14:08 we wait? 16:14:40 stassats [~stassats@wikipedia/stassats] has joined #sbcl 16:14:59 hangs in PCL... 16:15:17 same. 16:16:49 go back to the old way, but align to 64 KB and shift the lower 16 bits out? 16:17:12 I don't see how that's any better 16:18:41 conversion is trivial both ways, and things will fit in 32 bit 16:21:22 if we're in catch_exception_raise, have the other threads been suspended/stopped somehow? 16:21:50 only the one we're catching for, I think. 16:22:51 so why would we hang trying to acquire all_threads_lock? 16:23:16 we're ralking all_threads. At any moment, the thread struct we're traversing might be deallocated 16:23:21 *walking all_threads 16:23:34 sure, but who has the lock we're waiting on? 16:24:24 whichever thread that's executing post mortem handlers 16:25:11 and why can't that thread just finish and give us the lock? 16:26:19 pthread_kill is async, so the only think I can see is that we're holding all_threads lisp-side. 16:27:28 no, that makes no sense. 16:28:19 -!- hargettp [~hargettp@pool-71-174-136-63.bstnma.east.verizon.net] has quit [Quit: Leaving...] 16:30:58 hargettp [~hargettp@pool-71-174-136-63.bstnma.east.verizon.net] has joined #sbcl 16:31:14 one option is to let catch_exception_raise clean dead thread structs itself. 16:35:45 another option would be to have our own mapping from port names to threads, rather than squirreling away the port name in the thread struct 16:37:42 -!- hargettp [~hargettp@pool-71-174-136-63.bstnma.east.verizon.net] has quit [Quit: Leaving...] 16:46:28 we still have to clean it up somehow 16:47:14 threads tests pass without locking. ship it! 16:49:42 tcr1 [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 16:55:59 didn't really follow or understand this discussion, but are you in an exception handler trying to find your thread? 16:56:07 yes 16:56:41 we were using the address of the thread struct as the mach port name and 10.8 doesn't like that 16:57:07 if so, should you have access to the %fs register through the thread state argument? 16:57:30 shouldn't, I mean 16:57:45 remind me what's in %fs 16:58:15 the thread :-) 16:58:44 I new it was thread specific, but it's the address of the thread C struct? 16:58:46 knew 16:58:48 great 17:03:51 we could also use pthread_getspecific, no? 17:04:25 -!- wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has quit [Remote host closed the connection] 17:04:46 oh, no, we can't 17:05:01 wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has joined #sbcl 17:31:31 no, we're not *in* the thread. 17:33:09 could read it from thread_get_state? 17:34:11 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 244 seconds] 17:35:18 lichtblau: awesome (: 17:38:59 lichtblau: and r12 on x86-64, right? 17:40:14 huangjs [~huangjs@190.8.100.83] has joined #sbcl 17:55:16 yay 17:55:51 well, it's failing differently now (: 17:56:14 oh? it works for me. 17:56:39 %fs thing from thread_get_state? 17:56:47 r12 17:57:12 on x86-64. trying x86 right now. 17:57:43 I have (th->mach_port_name != exception_port) here 17:57:52 with th = (struct thread*)(thread_state.THREAD_BASE_REG); 18:19:22 ah, got it. mach_lisp_thread_init doesn't save to mach_port_name yet. 18:19:36 nope, not it. 18:24:06 r12 works great on x86-64, but fs doesn't work on x86. 18:25:11 do you do things different from http://paste.lisp.org/display/130755 ? 18:33:06 -!- slyrus [~chatzilla@adsl-99-190-99-176.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 264 seconds] 18:33:34 slyrus [~chatzilla@adsl-99-190-99-176.dsl.pltn13.sbcglobal.net] has joined #sbcl 18:33:46 damn internets 18:34:13 what I tried to say was: well, I don't check the port name :) 18:34:18 ah, I only load th on EXC_BAD_ACCESS 18:34:22 which are the only ones we need th for 18:35:24 ah, clever. 18:36:15 but, what about x86? 18:38:09 how does it fail on x86? 18:45:43 nope, can't use r12: signals in foreign code. 19:02:23 -!- tcr1 [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Quit: Leaving.] 19:07:27 wait, the only reason we need the thread here at all is for the control stack guard page stuff. if we're not in lisp code, we don't need to worry about that! 19:09:00 removing the check on mach_port_name == exception_port makes things work fine. I'm not sure which thread we're on where thread->mach_port_name isn't set. 19:12:38 I sometimes get downright wrong values for r12 though 19:15:11 "if we're not in lisp code, we don't need to worry about that!" -- erm, why not? 19:15:18 I think we have to keep our own mapping of port name <-> thread 19:18:01 I don't see how a separate mapping helps with correctness. Shouldn't it be protected by all_threads_lock, too? 19:18:55 hrm... 19:19:43 lichtblau: if it's disentangled from thread deallocation, it's easier to avoid accesses to freed memory. 19:21:58 I'd say just simulate Darwin's pthread_getspecific based on the context registers :-). 19:23:04 -!- wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has quit [Read error: Connection reset by peer] 19:23:07 gbyers had a discussion on that. Didn't seem fruitful 19:23:59 wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has joined #sbcl 19:24:56 tcr1 [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 19:26:59 -!- slyrus [~chatzilla@adsl-99-190-99-176.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 255 seconds] 19:28:09 I.e. he couldn't convince them to consider the internals as stable? 19:29:28 pretty much. I don't think he even managed to convey our use cases. 19:29:28 slyrus [~chatzilla@adsl-99-190-99-176.dsl.pltn13.sbcglobal.net] has joined #sbcl 19:29:45 otoh, an inline asm version is exposed, and used in LLVM 19:29:49 so it can't change that much. 19:32:02 http://svn.saurik.com/repos/cycript/trunk/include/pthread_machdep.h <- I think we're safe to use that. 19:47:34 -!- wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has quit [Quit: Client Quit] 19:53:14 TimKack [~user@d115007.upc-d.chello.nl] has joined #sbcl 19:55:07 slyrus: ok, I must be doing wrong. x86 works fine here. 19:56:26 oh, threadless build. Let's try again 20:23:55 pkhuong, "it's for occasions like these that I sometimes wish we'd move the runtime to C++" -- Do you agree or disagree that moving to C++ just opens the door to start using more esoteric C++ features, making it harder to compile on machines that perhaps don't have top-notch C++ compilers? 20:24:42 yes, there are pitfalls. We're already kind of heavy in gccisms iiuc. 20:25:08 stassats [~stassats@wikipedia/stassats] has joined #sbcl 20:25:43 I remember when the Factor programming language team moved from C to C++ for their runtime. They were happy about it, because in the end, the modularity and whatever ended up being more beneficial than the associated pitfalls, which could be solved by coding cleanly. 20:30:24 wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has joined #sbcl 20:30:30 slyrus: got x86 working 20:31:54 slyrus: http://paste.lisp.org/display/130755#1 20:35:30 -!- wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has quit [Read error: Connection reset by peer] 20:37:21 wow. how about x86-64? 20:40:21 working on it. 20:52:53 best I can see is to write to fs, perform the read, and restore fs, but that's madness. 20:53:03 * gs 21:05:12 any idea why r12 isn't always what we want? 21:12:30 edgar-rft [~GOD@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 21:30:04 slyrus: apart from foreign threads, no. 21:30:11 * threads in foreign code 21:41:15 -!- tcr1 [~tcr@84-72-21-32.dclient.hispeed.ch] has quit [Quit: Leaving.] 21:42:24 sdemarre [~serge@91.176.57.77] has joined #sbcl 22:01:02 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Remote host closed the connection] 22:01:13 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 22:05:41 wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has joined #sbcl 22:13:07 -!- sdemarre [~serge@91.176.57.77] has quit [Ping timeout: 272 seconds] 22:20:03 -!- wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has quit [Quit: none] 22:21:10 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Remote host closed the connection] 22:22:32 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 22:35:33 lichtblau: any idea why gs could be 0? 22:37:01 hargettp [~hargettp@pool-71-174-136-63.bstnma.east.verizon.net] has joined #sbcl 22:43:06 -!- TimKack [~user@d115007.upc-d.chello.nl] has quit [Remote host closed the connection] 22:45:22 kanru [~kanru@66.80.220.195] has joined #sbcl 22:47:13 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 246 seconds] 23:11:56 wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has joined #sbcl 23:23:31 I'm sure you've already figured it out by now 23:23:34 but for the record... http://stackoverflow.com/questions/11497563/ 23:27:51 -!- hargettp [~hargettp@pool-71-174-136-63.bstnma.east.verizon.net] has quit [Ping timeout: 272 seconds] 23:28:47 -!- edgar-rft [~GOD@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: lifetime expired] 23:29:26 well, that's just awesome. Mach doesn't get that right. 23:31:04 hargettp [~hargettp@pool-71-174-139-98.bstnma.east.verizon.net] has joined #sbcl 23:37:36 and those instructions are very new additions. 23:38:38 -!- wbooze [~wbooze@xdsl-78-35-131-161.netcologne.de] has quit [Quit: none] 23:43:08 pkhuong: of course r12 isn't set up to be the current thread when we're in the GC's C code... 23:46:39 looks to me like openmcl casts the exception port just like SBCL -- do they have the same bug? 23:48:13 good question 23:53:57 I give up. Align and shift.