00:25:25 -!- milanj [~milanj_@109-92-105-240.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 00:31:23 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 00:57:48 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 01:02:18 -!- christoph_debian [~user@oteiza.siccegge.de] has quit [Ping timeout: 244 seconds] 02:01:05 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 02:30:39 homie` [~levgue@xdsl-78-35-128-26.netcologne.de] has joined #sbcl 02:32:43 -!- homie [~levgue@xdsl-78-35-182-134.netcologne.de] has quit [Ping timeout: 244 seconds] 03:10:37 -!- peddie [~peddie@repl.esden.net] has quit [Ping timeout: 240 seconds] 03:11:30 peddie [~peddie@repl.esden.net] has joined #sbcl 03:24:28 attila_lendvai1 [~attila_le@87.247.17.192] has joined #sbcl 03:24:28 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 03:24:29 -!- attila_lendvai1 is now known as attila_lendvai 03:24:29 -!- attila_lendvai [~attila_le@87.247.17.192] has quit [Changing host] 03:24:29 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:01:56 -!- antgreen [~user@bas3-toronto06-1177889983.dsl.bell.ca] has quit [Ping timeout: 276 seconds] 05:30:39 -!- homie` [~levgue@xdsl-78-35-128-26.netcologne.de] has quit [Remote host closed the connection] 06:17:40 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has left #sbcl 06:18:37 attila_lendvai [~attila_le@87.247.17.192] has joined #sbcl 06:18:37 -!- attila_lendvai [~attila_le@87.247.17.192] has quit [Changing host] 06:18:37 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:33:35 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 276 seconds] 07:42:19 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 07:45:24 attila_lendvai [~attila_le@87.247.17.192] has joined #sbcl 07:45:34 -!- attila_lendvai [~attila_le@87.247.17.192] has quit [Changing host] 07:45:34 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:47:09 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 08:11:16 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 08:34:56 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 09:43:18 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 09:43:18 -!- ChanServ has set mode +o nikodemus 09:43:35 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:43:46 morning 09:44:05 hi nikodemus 09:45:20 pkhuong: once you wake... re mcas. i woke up with a thought: (cas (values place1 place2 ... placen) (values old1 old2 ... oldn) (values new1 new2 ... newn)) => prev1, prev2, ..., prevn 09:58:13 hlavaty [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 10:30:51 zyg [d572af0d@gateway/web/freenode/ip.213.114.175.13] has joined #sbcl 11:05:11 christoph_debian [~user@oteiza.siccegge.de] has joined #sbcl 11:24:45 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Remote host closed the connection] 11:25:40 hlavaty [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 11:38:26 udzinari [user@nat/ibm/x-dqqtffeoylpwlhaa] has joined #sbcl 11:51:14 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 11:55:45 attila_lendvai [~attila_le@87.247.17.192] has joined #sbcl 11:55:45 -!- attila_lendvai [~attila_le@87.247.17.192] has quit [Changing host] 11:55:45 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 12:30:11 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Disconnected by services] 12:30:13 nikodemus_ [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 12:30:35 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 12:30:35 -!- ChanServ has set mode +o nikodemus 12:32:32 homie [~levgue@xdsl-78-35-128-26.netcologne.de] has joined #sbcl 12:38:14 -!- nikodemus_ [~nikodemus@cs181056239.pp.htv.fi] has quit [Ping timeout: 276 seconds] 12:43:41 churib [~churib@95.156.194.105] has joined #sbcl 12:44:18 sbcl.org seems to have dns-problems... 12:51:02 mail sent to kevin (who handles the dns and holds the domain) 13:05:14 -!- churib [~churib@95.156.194.105] has left #sbcl 13:30:28 -!- tsuru` [~charlie@adsl-74-179-25-191.bna.bellsouth.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 13:30:42 milanj [~milanj_@109-92-103-199.dynamic.isp.telekom.rs] has joined #sbcl 13:32:00 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 260 seconds] 13:33:15 hi, by doing just (loop for foo = (sb-bsd-sockets:host-ent-address (sb-bsd-sockets:get-host-by-name SOME_DOMAIN))) I'm getting slowly memory usage growing (looking with top), but totally different figure with ROOM 13:34:12 it just past 130MB (32bit linux), ROOM is showing me 55MB 13:34:59 ... even after full GC 13:40:53 milanj: (or #+sb-bsd-sockets-addrinfo t) ; T or NIL? 13:41:51 T 14:05:49 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 14:06:09 milanj: i think i have a fix, just sec 14:15:03 tsuru` [~charlie@adsl-74-179-25-191.bna.bellsouth.net] has joined #sbcl 14:17:52 it leaks one word per call 14:23:35 my use case is something like 300 calls per second ... 14:39:44 i'm not belittling it -- i have a fix that i'm just now testing 14:40:04 homie` [~levgue@xdsl-78-35-189-167.netcologne.de] has joined #sbcl 14:40:27 (it also turns out that get-host-by-name and get-host-by-address weren't thread or interrupt safe outside getaddrinfo platforms) 14:41:57 -!- homie` [~levgue@xdsl-78-35-189-167.netcologne.de] has quit [Client Quit] 14:42:46 -!- homie [~levgue@xdsl-78-35-128-26.netcologne.de] has quit [Ping timeout: 244 seconds] 14:45:08 homie [~levgue@xdsl-78-35-189-167.netcologne.de] has joined #sbcl 14:48:38 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Remote host closed the connection] 14:50:37 yes, sure, just saying that it go unnoticed in more usual use case 14:50:38 ok, that was silly of me. for me get-host-by-name google.com takes 0.2-0.8 seconds. testing with localhost goes a lot faster... 14:51:43 i am kind of baffled by no-one complaining about the get-protocol-by-name leak before, though. it was fairly fast 14:51:57 yes, that one was pretty fast 14:52:20 nikodemus: oh, nice. 14:53:42 feh. still leaking 14:53:47 *nikodemus* squints 14:54:29 nikodemus: we can't really support arbitrary mcas anyway. 14:54:41 readers must go through a wrapper. 14:55:48 pkhuong: so no need for the extensible cas to support values, or support values without it being all-or-nothing, or make locatives the extension API? 14:56:55 Is the sbcl site down for anyone else or am I just lucky? 14:57:00 -!- sbryant- is now known as sbryant 14:57:05 nope down 14:57:06 sbryant: You aren't the only one. 14:57:17 sbryant: An email has been sent. It's being fixed. 14:57:36 dns problems.... 14:57:38 Great. 14:57:46 nikodemus: no need for (cas (values ...) ...) 14:59:27 In fact, I don't see how one could even implement cas/values without transactions. 15:00:17 -!- zyg [d572af0d@gateway/web/freenode/ip.213.114.175.13] has quit [Quit: Page closed] 15:02:25 pkhuong: well, you could make it (values (cas p1 o1 n1) (cas p2 o2 n2) ...) 15:02:37 but that seems to be of rather marginal utility 15:07:11 a-ha 15:07:16 an incidious typo 15:07:38 sockint::free-addrinfo != sockint::freeaddringo 15:07:57 the first is an sb-grovel generated deallocator... 15:12:28 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 15:12:35 G'morning all. 15:20:53 milanj: fix pushed 15:21:25 if you need a hotpatch, just copy the get-address-info from contrib/sb-bsd-sockets/name-service.lisp 15:22:13 nikodemus, thanks 15:36:16 antgreen [~user@bas3-toronto06-2925099223.dsl.bell.ca] has joined #sbcl 15:42:34 -!- udzinari [user@nat/ibm/x-dqqtffeoylpwlhaa] has quit [Remote host closed the connection] 16:25:00 win! well. or at least loss sighted! 16:25:30 i can now produce a semaphore with a positive count /and/ waitcount 16:25:38 now to figure out how it happens... 16:27:25 Wonderful! 16:27:31 nikodemus: are cancellation/deadlines involved? 16:27:55 I looked over the semaphore code, and it seems reasonably tight, though I'll admit to not having considered deadlines. 16:28:11 Which means that it's probably a mutex/condition issue. 16:29:35 nikodemus: convert them to spinafores and see if that fixes the deadlock? 16:30:14 That'd still leave the underlying issue, surely? 16:31:12 depends on whether the issue is with the semaphore implementation or mutex/waitqueue 16:31:16 huh. waitcount 20, waitqueue is empty 16:34:53 nikodemus: So, how are you managing these tricks? 16:35:05 And is this on x86oid or ppc? 16:35:28 x86-64, built the 32 bit version 16:35:28 (I'd figure x86oid, but also figure I may as well check.) 16:37:08 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 16:39:41 ahah. the :allow-with-interrupts in signal-semaphore seems to the culprit 16:41:24 no, i spoke too soon 16:41:29 just had a few lucky runs 16:42:39 nikodemus: is the barrier in release-mutex in the right place? 16:42:55 bah, the CAS is good enough anyway 16:47:32 i don't think the release-mutex even needs the :memory barrier. :write should be enough -- ie. nothing should be needed in ia32 16:48:15 the barrier is only in the "wtf are you doing" path, no? 16:49:04 nikodemus: ISTR that release-mutex provides a barrier guarantee in its description. 16:49:17 nyef: CAS does too. 16:49:23 and we release with a CAS. 16:49:28 Fair enough, then. 16:50:53 If you have a patch within about an hour and a half, I should be able to test it this afternoon. Otherwise, it'll have to wait until Monday. 16:59:35 computer algebra system 17:01:43 oh, right the :memory is only there in the :force case 17:02:09 feh 17:05:03 something isn't right here 17:28:59 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Disconnected by services] 17:29:01 nikodemus_ [~nikodemus@dsl-hkibrasgw4-fe5bdf00-15.dhcp.inet.fi] has joined #sbcl 17:29:20 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 17:29:20 -!- ChanServ has set mode +o nikodemus 17:37:41 -!- antgreen [~user@bas3-toronto06-2925099223.dsl.bell.ca] has quit [Remote host closed the connection] 17:47:15 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 17:47:25 can someone re-check %waitqueue-enqueue, -drop, and -wakeup for me? 17:47:46 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 17:47:59 ... They're all called from within a CAS-lock, right? 17:48:09 it seems that we get threads who still have thread-waiting-for set after they've been removed from the queue 17:48:14 yes 17:48:45 adding 17:48:46 (unless (waitqueue-%head queue) 17:48:46 (setf (thread-waiting-for me) nil) 17:48:46 :ok) 17:49:16 as a second leg of (OR ...) to the wakeup clause in CONDITION-WAIT seems to make it work 17:49:27 but i can't figure out what causes that to happen 17:49:42 Hrm. 17:49:52 ...probably something i've read N times and have become blind to 17:50:34 oh 17:50:39 i know 17:51:17 this is because i repurposed thread-waiting-for from the deadlock detection 17:52:31 where we have without-thread-waiting-for for GC and signals handlers and such 17:53:08 Stack-allocate a CONS? 17:53:25 stack allocation might not be a good idea. 17:53:33 Because...? 17:53:47 it's easy to get bugs with stale references from other threads. 17:54:09 so T1 is waiting on Q. T1 gets interrupted and is marked as no longer waiting. T2 does a wakeup, sees T1 in the queue but notices it is no longer waiting and just drops it. T1 resumes waiting, and never gets a wakeup 17:54:20 Only ever referred to from within the CAS-lock, though, surely? 17:54:25 nikodemus_: ah, nice. 17:54:32 Anyway, I have to go to lunch. 17:54:41 Back in a while. 17:58:03 option 1: special case the empty queue as above. Pro: simple. Cons: if the queue never becomes empty, the thread is never woken up. Not Good Enough. 18:00:13 option 2: make without-thread-waiting-for not restore the waiting-for information for a waitqueue, so it looks like a regular wakeup. Pro: simple. Cons: ? 18:01:24 con: perf issues with lots of signals, but meh. 18:01:28 Get it right first. 18:03:54 aha. this also explains the uninterruptible spins: same thing, but when trying to unwind from CONDITION-WAIT %WAITQUEUE-DROP starts spinning on with interrupts disabled (CDR NIL) because it doesn't handle case of "not in the list at all" 18:04:14 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Remote host closed the connection] 18:07:44 nikodemus_: so, if I read this right, we have the machinery needed to, later, have some notification object/thread? 18:08:13 read what right? 18:08:25 too many contexts 18:08:38 So, currently, each thread has a wait-for slot, and we just spin/sleep on it. 18:09:31 But, we could add something to that logic so that instead of sleeping we perform a bounded wait on, e.g., an OS semaphore? 18:10:59 pkhuong: yes and no 18:11:15 i think if we do that the waiting-for slot again becomes just informative 18:11:42 as its original purpose was deadlock detection 18:11:47 the OS-triggered wake up could be informative, actually. 18:11:55 oh sure :) 18:12:21 no practical reason why we could not eg have pipe per thread 18:12:31 yup. 18:12:48 well, resource limits on x86-64. 18:13:10 well, we can allocate them lazily and recycle them 18:13:56 btw, how many cas is it to enqueue in a waitqueue? 18:14:44 it might make sense to switch to mcas and take out the spinlock, thus making most of our stuff automatically interrupt-safe. 18:15:51 might very well be 18:17:14 we might also move sb-concurrency:queue to core and use it for waitqueues 18:17:53 or just CAS to head and accept O(n-of-waiters) for wakeups 18:18:40 or forget about fairness. 18:19:48 udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 18:21:18 -!- udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has left #sbcl 18:21:25 udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 18:23:20 -!- udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has left #sbcl 18:23:28 udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 18:25:51 -!- udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has left #sbcl 18:26:40 pkhuong: i'm still planning on adding :fair as keyword for constructors 18:27:02 udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 18:28:51 -!- udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has quit [Client Quit] 18:29:07 udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 18:36:11 -!- udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has quit [Quit: Leaving] 18:36:30 let's see if darwin can now survive the full set of sb-concurrency tests... 18:39:24 ...17 clean runs so far. i think the previous best was 14 18:39:36 if it makes 100, i'll call it clean 18:41:34 hah. dead in the water at 19, but looking at gdb it's a pthreads-in-signals-handlers issue 18:49:51 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 248 seconds] 18:52:08 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 18:55:02 the x86/linux build, on the other hand, that tended to hang very quickly has now survived 55 rounds 19:02:40 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Ping timeout: 240 seconds] 19:19:33 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 19:20:05 antgreen [user@nat/redhat/x-jmgwavnbuqkuzllc] has joined #sbcl 19:26:04 Okay, I'm back from lunch. 19:26:15 And I see that you have some success? 19:28:38 yeap 19:28:50 it made the x86 issues go away so i committed it 19:29:24 it made things on darwin better as well, but ... still being bit by the nastiness in runtime, no surprise 19:30:17 i think i'lll head home now 19:30:25 Okay, enjoy your commute. 19:30:33 5 minute walk :) 19:32:09 Nice! 19:32:46 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 19:38:47 -!- nikodemus_ [~nikodemus@dsl-hkibrasgw4-fe5bdf00-15.dhcp.inet.fi] has quit [Ping timeout: 276 seconds] 19:54:53 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 19:54:53 -!- ChanServ has set mode +o nikodemus 19:57:59 nikodemus: Building now, should have time for a couple of runs of threads.pure before I have to head out the door. 20:20:22 Is there an SBCL primitive that reads 8 unaligned octets as a little-endian word from a specialized octer vector and returns them as an unsigned 64-bit integer? 20:21:55 reb````: FFI and byte swapping if needed. 20:24:39 It's fairly simple to write just in terms of AREF, surely? 20:25:31 I have such accessors in my personal library out to 32 bits for both signed and unsigned. 20:25:57 Sure ... I have an inlined function that calls aref, shifts, adds. 20:26:29 I was just curious whether I could get better performance (for SBCL) by calling a magic primitive. 20:27:18 Not portably. 20:27:31 ... And it's not hard to CREATE a magic primitive. 20:28:17 On my Intel box I'd get one instruction instead of 40. 20:28:38 ok, just thought I'd check to see if one already exists. 20:28:40 nyef: or just FFI. 20:29:48 For the FFI approach, wouldn't I need to wrap the code in without-interrupts or something, since I'd have to find the address of the vector, then add in the byte offset before fetching a word. 20:30:24 no. You can pin the vector and then get its vector-sap. 20:33:21 Yeah, pin the vector. 20:33:38 Mind that some platforms really don't like unaligned word accesses. 20:33:59 What's the name of the function that pins a vector? Sure ... happy to just have a solution for x86. 20:36:34 it's sb-sys:with-pinned-objects and sb-sys:vector-sap. A couple libraries do that already (e.g. ffa). 20:37:12 Thanks! 20:39:01 which reminds me: an bunch of packing and unpacking functions (and vops) would be a nice thing to provide 20:40:11 *nikodemus* takes a stab at replacing the condition variable usage in runtime with realtime semaphores 20:41:02 I think Lisp machines have a way to point vectors of different types at the same block of memory, so that one reads the data as octets, while another treats it as fixnumbs. That sort of thing would be handy too. 20:48:06 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 258 seconds] 20:48:57 reb````: yeap. keeping track of the length of the array is the only really tricky bit for that 20:49:25 as ever, patches are most welcome :) 20:50:00 AHA. i think i know why my last attampt at semaphorification failed 20:53:19 heyaa. it builds, and threads aren't /totally/ broken 20:53:41 -!- homie [~levgue@xdsl-78-35-189-167.netcologne.de] has quit [Read error: Connection reset by peer] 20:53:51 Good news on the PPC front, it just ran threads.pure all the way through once. 20:54:15 \o/ 20:54:27 I have a second run going now, but then I have a train to catch. 20:54:40 homie [~levgue@xdsl-78-35-189-167.netcologne.de] has joined #sbcl 20:56:22 threads.pure and impure work, except for the scaling test -- which is a new failure 20:57:28 SVIT.3 is still going, and almost done, so I'm almost ready to call it good. 20:57:46 -!- homie [~levgue@xdsl-78-35-189-167.netcologne.de] has quit [Read error: Connection reset by peer] 20:58:47 homie [~levgue@xdsl-78-35-189-167.netcologne.de] has joined #sbcl 20:58:52 And the second run completed. 20:59:31 and i got a spectacular hangup... 20:59:36 Lovely. 20:59:47 So, I have to run. 20:59:50 (on darwin, with the semaphore changes) 21:00:02 Good luck, then. 21:00:09 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 21:00:48 Kryztof [~user@81.174.155.115] has joined #sbcl 21:00:48 -!- ChanServ has set mode +o Kryztof 21:00:55 -!- homie [~levgue@xdsl-78-35-189-167.netcologne.de] has quit [Client Quit] 21:06:32 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 276 seconds] 21:08:18 homie [~levgue@xdsl-78-35-189-167.netcologne.de] has joined #sbcl 21:32:35 -!- antgreen [user@nat/redhat/x-jmgwavnbuqkuzllc] has quit [Read error: Connection reset by peer] 21:53:43 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 22:22:36 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 244 seconds] 22:29:09 prxq [~mommer@mnhm-5f75c4f3.pool.mediaWays.net] has joined #sbcl 22:43:05 hah, lovely 22:44:09 sem_init fails with ENOSYS 22:44:32 what a joke of an OS 22:46:28 no wonder things don't work properly 22:47:29 what, you expect that if one part of an API is provided, the other parts are too? 22:48:07 Next thing, you'll be saying that poll and kqueue should work on a pty, just because select does! 22:48:22 nikodemus: ah, darwin? yes. 22:49:36 Besides, why aren't you using mach semaphores directly? Mach rulez, posix droolz! 22:50:08 options: (1) forget about it (2) use a single named semaphore on darwin, per thread-sems elsewhere for thread state changes (3) roll our own from xadd and nanosleep (4)? 22:50:33 foom: the docs say mach semaphores aren't safe to use in interrupt handlers... 22:50:45 for waiting or for signaling? 22:50:57 they don't bother to get that specific 22:51:05 but we need to be able to do both, so 22:51:13 Wait, and you think posix semaphores are? 22:51:16 mach doc says signal is safe for interrupt service routines. 22:51:35 sem_post and sem_wait are explicitly asynch signal safe 22:52:09 ...even on OSX? :) 22:53:55 well, at least they're supposed to be, unlike the mutexes and condition variables we now use... 22:55:00 oh well 22:55:31 i guess i'll have to give mach semaphores a whirl 22:55:38 but not today 23:04:31 https://www.google.com/codesearch#pFm0LxzAWvs/darwinsource/tarballs/apsl/xnu-792.tar.gz|O_WJd_UyLFk/xnu-792/bsd/kern/posix_sem.c&exact_package=http://www.opensource.apple.com/darwinsource/tarballs/apsl/xnu-792.tar.gz&type=cs 23:04:31 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 23:04:50 the posix semaphore functions indeed just call the mach ones, as one might suspect. 23:05:55 So, if the mach ones aren't signal-handler safe, I really don't see how the posix ones would be either. 23:10:14 (and too bad about google codesearch being discontinued, so don't keep that url too long, ah well) 23:15:04 -!- sdemarre [~serge@91.176.142.225] has quit [Ping timeout: 240 seconds] 23:15:20 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 260 seconds] 23:17:22 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 23:25:40 -!- homie [~levgue@xdsl-78-35-189-167.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 23:27:27 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 23:31:08 sdemarre [~serge@91.176.94.227] has joined #sbcl 23:33:30 mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has joined #sbcl