***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>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 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>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>i think they are not present there <wingo>ACTION accidentally did a "make clean"; guess that means it's lunchtime :P <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 :-) <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 <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>basically any runtime facility that compiled code will need, but which you don't want to inline <civodul>i see, things that in 2.2 are typically instructions or primitives <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>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 was also thinking we could release 2.2.4 soonish <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 <civodul>what about making the import obarray a weak-key hash table? <wingo>yes but that has more long-term gc overhead <civodul>i wonder if the global mutex could lead to contention <civodul>OTOH, like you write, there's scheme-level caching as well <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. <sahithi-ihtihas>In procedure vector-length: Wrong type argument in position 1 (expecting vector): #f <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