freenode/#sbcl - IRC Chatlog
Search
18:20:31
stassats
is there a rationally for poorly implementing our own mutexes and condition variables?
18:22:51
jsnell
I would have guessed it was another of those cases of system calls actually working properly on OS X
18:24:34
nyef
stassats: IIRC, the memory requirement for futexes is a single (unboxed?) word, plus possibly kernel memory overhead /while they are being slept on/.
18:26:42
nyef
So no foreign objects to track that can leak, for example. A winapi mutex is represented by a HANDLE, but it's tied to some kernel state that can leak.
18:30:41
jsnell
I'm trying to remember whether that special support was anything except custom finalizer machinery. probably not
19:28:28
stassats
i'd be fine with that, as i'm fine with using dispatch_semaphore in slime, but something available to a wider audience would be preferable
19:31:22
stassats
i still think any normal program shouldn't create and discard too many mutexes, so finalizers should do
19:58:05
fortitude
is it normal for a thread in gc_stop_the_world to have GC_INHIBIT and IN_WITHOUT_GCING set? relatedly, shouldn't gc_start_the_world set IN_WITHOUT_GCING to NIL, or a stored value?
20:32:42
foom2
Google open sourced the C++ Mutex implementation we use internally. It doesn't use pthread mutex, instead using some sort of per-thread waiter or something like that.
20:33:02
stassats
we could even detect that a function is only using a hash-table to call gethash/puthash and not lock it
20:34:15
stassats
foom2: the current sb-thread:grab-mutex works everywhere too, but it doesn't unscheduled itself and has to spin instead
20:35:46
stassats
i still imagine a proper pthread_mutex can use better techniques than just sleeping
20:35:58
foom2
https://github.com/abseil/abseil-cpp/blob/master/absl/synchronization/internal/waiter.cc
20:40:57
foom2
But in any case, the possibly-heavyweight platform-specific stuff is only used to implement blocking, and so there's only one per thread.