IRC channel logs


back to list of logs

***Raimondii is now known as Raimondi
<lloda>looks like the kind of thing that would be done to check an interface, but it's funny to have it documented. I mean (car) isn't documented (in the repl) :p
***Raimondii is now known as Raimondi
<civodul>hi there!
<wingo>heya civodul :)
<civodul>i'm looking at the multi-threading bugs we have in Guix
<civodul>one issue we have presumably is the non-thread-safe manipulation of the 'autoloads-done' alist
<civodul>in boot09
<civodul>in theory we could add a "with-mutex" in try-module-autoload
<civodul>or we could use an atomic box, but OTOH we're on the slow path already
<wingo>the solutions there are easy, the problem is just getting things right in terms of boot order :)
<civodul>right, that's what i was afraid of :-)
<civodul>so 'make-mutex' is not available at early boot, is it?
<wingo>i see three options. serializing all module loads with a big fat mutex, or preventing multiple threads from loading the same module at the same time with a mutex and a cond in the module loader code, or adding an "initialized?" flag, a mutex and a cond to each module object
<wingo>civodul: i think it is available, yes.
<wingo>humm. it's defined in c but only loaded in the (ice-9 threads) extension.
<wingo>maybe we can make it so that loading (ice-9 threads) mutates the module loader, replacing some part of it
<civodul>adding a mutex in each module would be useful longer term (to allow concurrent mutations of the module's bindings), but that's another story (API breakage, etc.)
<wingo>that might be the right thing; before (ice-9 threads) is loaded, there aren't multiple threads
<civodul>we could wrap the body of try-module-autoload in 'call-with-big-fat-mutex'
<civodul>call-with-big-fat-mutex would just call its argument initially
<civodul>and then, once (ice-9 threads) is loaded, it would take a mutex
<civodul>something like that
<civodul>ACTION emails bug-guile for posterity
<wingo>yes that is probably the simplest thing that can work. if we could avoid adding another name to the default namespace, that would be the best; dunno if that's possible though
<civodul>currently make-mutex & co. are in the default namespace but they're deprecated
<wingo>ah, i was looking at 3.0 :)
<wingo>i think they are not present there
<wingo>ACTION accidentally did a "make clean"; guess that means it's lunchtime :P
<civodul>wingo: here's a simple patch that does the job:
<wingo>civodul: lgtm, but wdyt about making (ice-9 threads) just do a set! on call-with-module-autoload-lock ?
<wingo>then you could use with-mutex etc
<wingo>it's more like normal programming at that point
<wingo>of course a recursive mutex is not great. i.e. generally they reflect a bad design. and in this case it will mean we are serializing a lot of code in the guix context
<wingo>but, i think it can work here.
<wingo>civodul: that way, if we managed to make the (ice-9 threads) load be lazy at some point, then we would put off the mutex until ice-9 threads is indeed loaded
<wingo>i think it's not bad how you have done it tho :)
<civodul>wingo: oh sure, we can move set! to (ice-9 threads)
<civodul>regarding the recursive mutex, i kinda agree
<civodul>though here i don't have a better idea :-)
<civodul>wingo: the updated version:
<civodul>cool, thank you!
<wingo>btw by way of status -- i have been massaging libguile on master so that the vm calls out to the runtime only through a structure containing some function pointers and such
<wingo>of course it can call anything via gsubrs or foreign functions or whatever, but this refers to the functioning of the vm itself
<wingo>e.g. "allocate some words", that sort of thign
<wingo>that will make it so that this structure can live in a register, and jit code can call out to the runtime through that structure, calling functions at known offsets with known ABI
<wingo>it has taken a bit of time :) i am getting there tho
<civodul>oh that sounds fun, i need to get up to date with 3.0
<civodul>you're living in the future! ;-)
<wingo>also some scheme primitives compile to calls to functions at known offsets, e.g scm_add and such. when jitted, we'll get to replace that with direct calls
<civodul>so which functions would be called this way?
<wingo>known offsets in the "intrinsics" structure
<wingo>ACTION looks for link
<wingo>basically any runtime facility that compiled code will need, but which you don't want to inline
<wingo>initialized here:
<civodul>i see, things that in 2.2 are typically instructions or primitives
<wingo>right, in 3.0 you will end up compiling to e.g. call-scm<-scm-scm with the offset of the "add" instrinsic,
<wingo>the idea being that it will be less work for a JIT to just implement compilers for the different function types
<wingo>instead of implementing compilers for all the instructions we might want
<wingo>also this way there are fewer callouts from the C VM, so fewer opportunities to forget to SYNC_IP() etc...
<wingo>maybe more precisely: things that in 2.2 are instructions but which are too big to inline
<civodul>yes, there are a few big instructions
<civodul>and in 2.2 you'd have to implement them entirely in lightning or whatever JIT library you're using
<civodul>which could be a pain
<civodul>intrinsics should definitely make that easier, that's nice
<wingo>i think probably lightning will be the thing
<civodul>ACTION pushes a few old patches to stable-2.2 \\o/
<civodul>eb90831ce * Add SRFI 71: Extended LET-syntax for multiple values.
<rekado_>civodul: should we apply your patch to fix the “autoloads-done” problem to the Guile package in Guix?
<civodul>rekado_: i was thinking we could monkey-patch this
<civodul>i'll give it a try
<civodul>i was also thinking we could release 2.2.4 soonish
<wingo>sgtm :)
<civodul>wingo: next comes the import obarray: :-)
<wingo>civodul: what about adding a global low-level pthread mutex to module.c and use it when accessing the import obarray? if it's not accessed from scheme that will be sufficient
<wingo>since scheme code caches lookups it won't be a long-term cost, and low-level pthread mutexen are relatively free... we could acquire the mutex only if guile is initialized, if that's a win
<wingo>we could of course just make hash tables thread-safe :)
<civodul>wingo: you mean a global mutex, not a module-specific mutex, right?
<wingo>yes i was suggesting a global mutex for access to any import obarray
<wingo>dunno, just an idea
<civodul>what about making the import obarray a weak-key hash table?
<civodul>which is thread-safe
<wingo>yes but that has more long-term gc overhead
<civodul>right, good point
<civodul>i wonder if the global mutex could lead to contention
<civodul>OTOH, like you write, there's scheme-level caching as well
<civodul>wingo: i think i'll go with the simple-yet-efficient approach that you proposed:
<civodul>how does that sound?
<wingo>civodul: lgtm!
<wingo>thank you :)
<wingo>ACTION goes home
<sahithi-ihtihas>Can someone Explain how match:count works with an example
<rekado_>sahithi-ihtihas: “match:count” needs to be applied to a match structure, i.e. the result of applying “string-match”.
<rekado_>sahithi-ihtihas: it returns the number of sub-expressions that have matched the target string.
<rekado_> /me needs to leave now
<sahithi-ihtihas>Thanks Ricardo
<sahithi-ihtihas>In procedure vector-length: Wrong type argument in position 1 (expecting vector): #f
<sahithi-ihtihas>what does this error specify??
<wingo>good evening
<OrangeShark>hello everyone
<daviid>afternoon greatings here :)
<daviid>our beloved maintainers seems to be in bug tracking mood! pretty cool to read the emails, fixed, fiex, fixed ...
<daviid>though i haven't been drinking any wine today, I keep reading 'subtropical experience' (instead of 'suboptimal experience') haha