IRC channel logs

2013-11-15.log

back to list of logs

<unknown_lamer>mark_weaver: I can try it against stable-2.0 honestly
<unknown_lamer>if it only requires slight dusting off against the 2.0 vm
<unknown_lamer>I just want to verify that boxed floats are the primary culprit, and not something like the gc collection interval heuristic breaking under the particular load
<mark_weaver>yeah, I could make a patch for 2.0 easily enough.
<mark_weaver>I'll try to get something to you sometime next week. at the moment, I really need to focus on tupi's problem with (ice-9 popen) thread (un)safety.
<mark_weaver>part of the problem is that stable-2.0 now has assembly language snippets for three architectures that need to be updated for nan-boxing.
<mark_weaver>(I first wrote that patch when the asm for only there for one arch)
<mark_weaver>s/for only there/was only there/
<mark_weaver>going offline for a while. ttyl!
<unknown_lamer>assembly!
<unknown_lamer>boo
*davexunit is reading about monads. mind bending stuff.
<zacts>does guile allow for monads?
<zacts>I saw it mentioned in SICP somewhere..
<davexunit>zacts: scheme has everything you need: lambda :)
<zacts>cool!
<zacts>yeah, everything can be represented by a function it seems, if I understand correctly.
<zacts>everything is movement
<b4283>zacts: you sound like a philosopher
<davexunit> http://okmij.org/ftp/Scheme/monad-in-Scheme.html
<zacts>b4283: I'm quite fond of plato's theory of forms
<zacts>lol
<zacts>:D
<b4283>that everything is imperfect reproduction of its ideal form
<zacts>yes
<b4283>i picked it up long time a ago, that's all i can recall :P
<zacts>I think philosophy can be cool as long as you don't think about it
<zacts>it's like musical scales, you just learn them and forget them into your subconcious
<zacts>lol
<zacts>monads are important in haskell iirc
<zacts>it encapsulates non-functional stuff in an api or something like that, or am I totally wrong?
<zacts>I'm also learning as a newbie
<davexunit>a good example for using the monad pattern is a random number generator
<davexunit>to do it functionally, one must pass in the current seed value to every procedure that needs random numbers
<zacts>so how is monadic programming different from procedural programming?
<zacts>what abstraction do monads provide?
<zacts>that sequential procedures do not?
<zacts>my understanding is that programming gets interesting, and possibly buggy, when you introduce sequence of actions..
<zacts>or non-pure functions, aka non-functional procedures
<davexunit>with a monad, the sequence of actions enforced.
<zacts>oh interesting..
<davexunit>it's one big nested series of functions
<zacts>so it's more linear?
<zacts>rather than spaghetti?
<davexunit>keep in mind that I don't really know much about monads, so everything I'm saying is likely a) not quite right or b) quite simplistic.
<zacts>that's cool, I don't know anything about monads either, and our conversation is rather interesting anyway
<zacts>my current understanding is monads == an api into a linear sequence?
<zacts>probably not correct, but one day I'll read learn you a haskell and SICP
<davexunit>"Monads provide a generalized interface to sequential computation."
<davexunit>according to schemewiki
<zacts>sounds similar to my definition
<zacts>:-) \\o/
<davexunit>yeah
<nalaginrut>morning guilers~
<zacts>hey
<b4283>morning
<zacts>there are lots of cool 'real world' guile projects in the brew it seems
<zacts>guix / guilemacs / guile-wm / ...
<nalaginrut>I think you can mimic monad in Scheme in many ways, http://www.ccs.neu.edu/home/dherman/research/tutorials/monads-for-schemers.txt
<davexunit>there is a neat chicken scheme library for monads http://wiki.call-cc.org/eggref/4/monad
<nalaginrut>yeah~
<davexunit>I've heard people describe jquery as a sort of monad.
<davexunit>I don't know what truth there is to that, but on the surface I can see the resemblence.
<davexunit> http://paste.lisp.org/display/139939
<davexunit>here's my first try with monads
<davexunit>JS libraries like jquery and underscore use this sort of pipelining idea to work their magic.
***madsy is now known as Madsy
*nalaginrut encountered a problem, when he load a module, it cause Guile quit, strange
<b4283>the module includes (exit) ? :P
<nalaginrut>no, I don't think so, except for my mistake ;-P
<Madsy>Hm. The finalizers in the next guile version would run in its own thread, right?
<Madsy>In that case, is it possible to revert it back to the old behavior?
<Madsy>I'm trying to think long term, and my finalizers do work that have to be done in the current thread
<civodul>Hello Guilers!
<nalaginrut>heya ludo
<Madsy>hey civodul :)
<lloda>wingo: when you have time, let me know if I can help
<civodul>he's not here :-)
<Madsy>civodul: Are you a guile developer?
<nalaginrut>Madsy: you are a freshman ;-D
<lloda>civodul: I wasn't here either when he posted :)
<Madsy>nalaginrut: I am indeed
<civodul>lloda: use sneek's "later tell"
<civodul>Madsy: yes, although i've been MIA for some time
<Madsy>The srfi sources is a nice read when implementing new guile functions
<Madsy>Seems like the doc strings have a kine of markup syntax that texinfo understands
<Madsy>kind*
<civodul>Madsy: actually docstrings in Scheme code are left uninterpreted currently
<civodul>so if you use Texinfo markup in there, it will appear as-is in 'help' and Geiser
<civodul>(that may change in the future)
<Madsy>civodul: Ah, okay. I just saw that srfi-1.c used them
<Madsy>For example, the docstring of append-reverse uses "@var{tail}"
<civodul>srfi-1.c is C, so it can use them, yes
<Madsy>civodul: That's the docstrings I was talking about
<Madsy>But okay, I see. So scheme docstrings and C docstrings don't follow the same path
<nalaginrut>I know why Guile quits after loading my module, it's all the problem of my delimited-continuation using...
<civodul>Madsy: exactly
<Madsy>But hmm.. newlines don't seem to work like they should
<Madsy>Is that a known bug or limitation?
<Madsy>This is what happens: http://www.mechcore.net/images/misc/docstring.png
<mark_weaver>civodul: might you have a few minutes to answer some questions about boehm GC and guardians? I need to make guardians thread-safe in order to make (ice-9 popen) thread-safe, which tupi desperately needs.
<Madsy>Hey mark_weaver :)
<Madsy>mark_weaver: I got docstrings working!
<mark_weaver>Madsy: that's good!
<Madsy>mark_weaver: I was wondering. You told me a day ago that the latest GC will do the finalizers in its own thread. Will it be possible to tell the GC to not run during a form?
<Madsy>I'm thinking long-term, and my code will not work with finalizers in a second thread. OpenGL is weird like that.
<mark_weaver>Guile 2.2 will run finalizers in its own thread. Guile 2.0 doesn't do that.
<Madsy>Right. That's why I said long-term. I'd like my code to just work (tm) when I migrate to Guile 2.2
<mark_weaver>Madsy: can't you solve the problem using thread synchronization, or by having the finalizer send a message back to the main thread, or something?
<mark_weaver>there
<mark_weaver>there's really no sane way to do finalizers without running them in a separate thread, in the general case.
<mark_weaver>but have you looked at guardians? they might solve your problem nicely.
<Madsy>mark_weaver: It's difficult. Basically you can't run OpenGL cleanup functions from a second thread, unless the first thread calls glXMakeCurrent(NULL), and the new thread calls glXMakeCurrent(context)
<Madsy>They have to change ownership of a context object
<Madsy>Not only that; the operation is crazy expensive. It can take up to several miliseconds
<mark_weaver>(see http://www.hpl.hp.com/techreports/2002/HPL-2002-335.pdf for an in-depth description of the problems with running finalizers in an existing thread)
<mark_weaver>Madsy: I think guardians will do what you need.
<mark_weaver>you register an object with a guardian, and then you periodically ask the guardian if there are any unreachable objects that it was guarding.
<Madsy>ok
<Madsy>As long as it's possible, the solution can be as hairy as it wants
<mark_weaver>the thing is, we can't just run your finalizer in an existing thread without knowing when would be a safe time to do it.
<Madsy>right
<mark_weaver>otherwise you end up in deadlock hell.
<mark_weaver>Madsy: out of curiosity, what would you see as an ideal solution to this problem?
<Madsy>Maybe a macro or primitive that stops the GC from running during a form. A kind of critical section.
<Madsy>But maybe that's a worse idea than it sounds. This is clearly not my field of expertise :)
<Madsy>But maybe that's what you meant with a guardian?
<mark_weaver>well, guardians are different than blocking GC. with guardians, GC is not blocked, but rather, the finalizers are effectively postponed until you explicitly check for any pending finalizers (among the set of objects you'
<mark_weaver>you're interested in)
<Madsy>okay
<mark_weaver>part of the problem is that a time that would be good to run a finalizer for one set of objects is not necessarily a good time to run finalizers for some other set of objects, managed by a different piece of code.
<mark_weaver>I see no good way to choose a good time to run some arbitrary finalizer.
<mark_weaver>arbitrarily interrupting a thread to run some other piece of code within its context is a can of worms, I think. it's hard to avoid deadlocks and data corruption.
<mark_weaver>in the general case, you'd need to avoid running "asyncs" (e.g. a finalizer in an existing thread) whenever any lock is held, or when any data structure is in an inconsistent state.
<mark_weaver>but of course, some locks are held a long time, so that's no good.
<mark_weaver>and there's also no way for guile to know when all data structures (that might be accessed from a finalizer) are in a consistent state.
<Madsy>mark_weaver: Oh, another thing. Are newlines supposed to work with the docstrings?
<mark_weaver>yes
<Madsy>They seem to be ignored here. But not all of them. I can't explain it.
<Madsy> http://www.mechcore.net/images/misc/docstring.png
<Madsy>Each keyword in the docstring should start on its own line
<Madsy>I better check the intermediate .doc and .texi files
<mark_weaver>well, it looks like your docstring is getting processed by texinfo, as we do with docstrings of procedures defined in C (and I think plan to do with procedures defined in Scheme at some point).
<mark_weaver>so probably it has to do with that, although I know very little about texinfo.
<mark_weaver>(I confess that I normally look in the guile texinfo sources for examples of what I want to do, and base my texinfo code on that)
<Madsy>Yep. That's what I did. Went hunting in the makefile :)=
<Madsy>Then I had to copy 3 scripts over
<mark_weaver>I suspect that if you want to list a bunch of keyword arguments, that you should use one of the texinfo itemized list commands.
<Madsy>Good idea. Thanks.
<mark_weaver>probably @itemize and @item
<mark_weaver>(and @end)
<civodul>hey mark_weaver
<civodul>mark_weaver: no, sorry, not now
<mark_weaver>hi civodul!
<mark_weaver>okay
<civodul>unless it's a simple question
<civodul>:-)
<mark_weaver>it's okay. maybe later today or tomorrow?
<civodul>yes
<civodul>or you can send an email
<mark_weaver>I'd prefer chat, since it might involve some back-and-forth, and I promised tupi a patch by Sunday. I'll ping you later today.
<civodul>ok
<Fuuzetsu>davexunit: Just the person I was looking for 9 hours ago.
<davexunit>Fuuzetsu: there are huge chunks of time, at night, when I just sleep.
<davexunit>:P
<Fuuzetsu>Never heard of it happening. Anyway, I saw few weeks ago that you went into #clementine and asked about libre.fm integration. Are you still doing that? And to keep somewhat guile related, I saw your silly monad paste (missed you by few minutes)
<davexunit>Fuuzetsu: I gave up on clementine because the library they use for scrobbling is hardcoded for last.fm only. too much work for me to bother.
<davexunit>Fuuzetsu: and yes, I made a real silly monad paste. baby steps, man.
<Fuuzetsu>davexunit: Ah. Actually I considered doing the libre.fm support months before you did but came to the same conclusion.
<Fuuzetsu>I started proving your monad but got distracted since. I might postulate some tedious mid-way proofs and finish it in a sec
<davexunit>I don't really like clementine, but it was the best free software music playing application that I could to use on OS X here at work.
<Fuuzetsu>(Honestly though, I'd imagine that Maybe would be people's first self-thought monad)
<davexunit>Fuuzetsu: I expanded my code a bit more after I made that paste. I added a pipeline procedure that works in a similar manner (from what I can tell) to "do" in haskell.
<davexunit>oh wait, that was in the paste.
<davexunit>I had omitted lift and compose.
<Fuuzetsu>You don't need those, those follow automatically from bind and return
<davexunit>compose is a nice primitive because you can then define lift as a composition of "return" and "f"
<davexunit>it's like the magic of cons
<Madsy>When I pass strings to functions like scm_misc_error(), can the strings live on the function stack?
<Madsy>It doesn't do any fancy longjmp or signaling before displaying the string, right?
<Fuuzetsu>I couldn't do something though that I didn't understand. I couldn't do code like (>>= (square -2) (>>= (lambda (x) (half x)) square))
<Fuuzetsu>guile complains that it's expecting a pair…
<davexunit>reverse the arguments to the outer bind?
<davexunit>I had this: (>>= (>>= (return 4) square) half)
<Fuuzetsu>davexunit: the problem with monads in Scheme is that it looks disgusting
<davexunit>I don't really think so.
<davexunit>especially not with a macro or two on top.
<Fuuzetsu>davexunit: no no, the idea is that I should be able to do this according to the associativity law
<davexunit>Fuuzetsu: so there's probably something wrong with my implementation that I should address. :)
<Fuuzetsu>davexunit: now another macro or two for a proper type system ;P
<davexunit>Fuuzetsu: getting an optional type system like racket has is something that some guilers, want.
<davexunit>s/,//
<Fuuzetsu>davexunit: I think your implementation fulfills the laws fine (I'll finish the proof in a bit), I must just be misunderstanding the evaluation semantics
<Fuuzetsu>Too bad that Racket's type system is… not so great ;P
<davexunit>I think type systems are cool, but I much enjoy the malleability of Scheme.
<davexunit>blasphemy, I know.
<Fuuzetsu>I just can't see the benefit of no static safety nor inability to do any type tricks.
<Fuuzetsu>Just today I used a type system to enforce a statically safe list with alternating elements of two different types!
<davexunit>that is cool.
<davexunit>I think haskell is great, and I imagine many other schemers agree.
<wingo>ahoi
*wingo rewrite slot allocation to try to allocate arguments directly in their slots
<wingo>*rewrote
<cky>I wonder if slots are also used for return values.
<cky>MMIX's architecture uses the low-numbered registers for receiving arguments, and for returning return value(s).
<cky>(Yes, built-in MV in the instruction set!)
<wingo>i am mmix-ignorant, but guile's instruction set sounds similar in that regard
<mark_weaver>wingo: I read the backlog. I'm sorry if my message had a bad tone to it. I did not intend any such tone, but admittedly my social skills are not all that good, so I'll take your word on it.
<wingo>mark_weaver: hey, i wanted to apologize for that too
<wingo>sorry for the snark!
<wingo>anyway you are totally right, is the thing
<mark_weaver>np
<wingo>we need to align on the maximum page size for an architecture, it seems
<wingo>basically doing whatever the gnu linker does i think
<wingo>wdyt?
<mark_weaver>I see now that indeed, we need to pick some maximum page size per architecture.
<wingo>cool
<mark_weaver>yeah, I think we should try to emulate what GNU binutils does.
<dsmith-work>Happy Friday, Guilers!!
<wingo>howdy dsmith-work :)
*wingo removing mvra
<mark_weaver>cool
<mark_weaver>wingo: I guess this also means that the cache directory name (that includes the word size and endianness) will also have to include the page size.
<wingo>mark_weaver: sure
<wingo>well, will it?
<wingo>hum
<wingo>i guess just using the target triplet is too coarse
<wingo>or too fine!
<wingo>i assume there are people that want to compile on 32-bit x86 and have it run on ARM, or similar
<mark_weaver>too fine, I think, although I suppose it's not terrible important.
<mark_weaver>*terribly
<wingo>yep
<mark_weaver>on systems with Linux headers, it seems that EXEC_PAGESIZE from <sys/param.h> is probably what we want.
<mark_weaver>but I guess we might need our own little database to support cross-compiling.
<mark_weaver>(grep EXEC_PAGESIZE arch/*/include/asm/param.h from a linux source tree)
<wingo>sure
<mark_weaver>alternatively, if there aren't too many objects that have to be page aligned, we could just fix it at the maximum for all supported architectures, which I guess is 64K.
<wingo>but this is part of platform abis, no? i would default to having a list of maximum sizes, and default to the current page size
<wingo>yeah that's also possible
<wingo>lots of possible solutions :)
<mark_weaver>roughly how many objects need to be page-aligned in a typical .go file? is it just one per segment, with some small number of segments?
*mark_weaver looks at some ABI docs
<wingo>mark_weaver: right, maybe three alignments per .go
<wingo>as you say, one per segment, with small number of segments
<mark_weaver>The MIPS N32 ABI doesn't mention page size at all. The SysV psABI for x86_64 says only this: that the page size can be any power of two between 4KB and 64KB.
<mark_weaver>I think maybe we should just make it a fixed 64KB. That would also save us the trouble of maintaining a table of platforms and their max page sizes, which would probably lead to portability problems.
<mark_weaver>and it's 64KB for x86_64 anyway.
<mark_weaver>WDYT?
<mark_weaver>(well, it's 64KB for x86_64 according to the ABI document, anyway. but admittedly EXEC_PAGESIZE is 4096 on my Debian x86_64 machine)
<mark_weaver>well, I guess I'm not sure what to do...
<mark_weaver>hmm, well, it's 4096 on my Debian MIPS box also, so I guess EXEC_PAGESIZE is no good.
<wingo>mark_weaver: 64kB sounds fine to me
<mark_weaver>cool, sounds good :)
<wingo>thanks for looking into this, and again, sorry for being cranky!
<mark_weaver>you're welcome. thanks for all the awesome hacking, as usual :)
<mark_weaver>wingo: should I push a commit like the one in my email, except with 65536 instead of 16384?
<wingo>mark_weaver: sounds good to me; the runtime check only needs to check that alignment is a multiple of the current page size, rather than any particular number; but it doesn't matter to me
<wingo>it would be possible to fall back to the malloc path instead of mmap if there was a mismatch, but that would be a big lose
<wingo>hoo, an -O0 guile is twice as slow as an -O2 guile :P
*wingo does a fresh rebuild, because no more mvra...
<wingo>no more mvra in master!
<mark_weaver>sweet!
<wingo>apologies for the bytecode churn, that should be it for a little while
<mark_weaver>I guess a rebuild will be needed when the page size goes to 64K, so I should do that soon.
<mark_weaver>wingo: does this look right to you? http://paste.lisp.org/display/139949
<mark_weaver>(I'll also test it before pushing)
<mark_weaver>(mostly I'm not 100% sure what the meaning of p_align is)
<mark_weaver>hmm, I guess in objcodes.c it would be better to get the actual page size at runtime.
<mark_weaver>though that will require doing some autofoo to find out if sysconf is available.
<mark_weaver>hmm, I wonder if there's a gnulib module.
<mark_weaver>ah good, gnulib has a getpagesize module
<Madsy>mark_weaver: Hey, that sounds very Windows-unfriendly ;-)
<Madsy>*points finger*
<mark_weaver>Madsy: no, the gnulib module handles that.
<mark_weaver>Madsy: On windows, it uses Windows native calls to find the page size.
<mark_weaver>Madsy: btw, if you would like to test guile on mingw periodically and help us fix problems as they arise, it would be very helpful.
<Madsy>Ah, nice
<Madsy>Sure, I'll test the mingw build, no problem
<Madsy>I need it anyway
<mark_weaver>excellent, thanks! :)
<mark_weaver>wingo: sorry, that last patch was sloppy. please forget it. I'm doing a more proper job now.
<dsmith-work>Hmm. Got a backtrace while building .go files. May have been because I had -j5..
<dsmith-work>I think it was in GUILEC system/vm/trace.go
<mark_weaver>dsmith-work: master or stable-2.0?
<dsmith-work>master
<dsmith-work>v2.1.0-830-gcb8ea38
<mark_weaver>well, first of all, wingo just made a change that requires "make clean".
<dsmith-work>Yes. I started from a git clean -dxf
<mark_weaver>but that aside, I also got a backtrace once when building master with -j4. and without -j4 it worked and passed all tests.
<dsmith-work>BUT I didn't purge any cached .go files..
<dsmith-work>Ah ha.
<dsmith-work>I suspected that.
<mark_weaver>oh, well, you need to purge the .go files.
<mark_weaver>(if you just pulled)
<mark_weaver>wingo: I've run into a problem with the page size patch.
<mark_weaver>apparently, p_align is supposed to be the minimum alignment of the segment in memory, i.e. p_offset = p_vaddr mod p_align
<mark_weaver>with the patch, it seems that p_align is getting set to 64K. but then a simple mmap of the .go file will not guarantee that alignment, unless the native page size really is 64K.
<mark_weaver>it seems to me that what we need is for the segments to be aligned on a 64K boundary within the .go file, but for p_align to be set to something smaller.
<mark_weaver>however, I confess that my knowledge of ELF is quite rusty, so maybe I'm confused.
<mark_weaver>(with my patch, things seemed to work and "make check" passed, but it occurred to me that I was failing to honor the constraint that p_offset = p_vaddr mod p_align)
<wingo>mark_weaver: sorry, had to step away
<mark_weaver>no worries.
<wingo>my knowledge of elf corrodes quickly
<wingo>it has a short half-life
<mark_weaver>heh, same here. I swear I knew more about it long ago :)
<wingo>:)
<wingo>so, good question re p_align... the loader doesn't actually care about the alignment except that each segment starts a page
<wingo>well
<wingo>maybe not each segment
<wingo>each segment that has different permissions from the previous segment
<mark_weaver>I think perhaps the segments should be aligned at 64K boundaries in the file, but that p_align should be something small like 8 or something.
<wingo>could be
<wingo>perhaps take a look using readelf -a on some system libs to see what they do
<mark_weaver>good idea.
<mark_weaver>hmm, I'm not sure which things in this output correspond to p_align. should I be looking at the 'Al' field in the "Section Headers"? (for things like .text, .rodata, .bss, etc)? I think so. those fields are all small, various values no more than 16.
<mark_weaver>but then, their "off" fields are usually not aligned either. although the 'addr' and 'off' fields of the '.got' section is aligned, even though "al" is only 16.
<mark_weaver>in the "Program Headers", with things like "PHDR", "INTERP", etc, most of those have small alignments also, but with two exceptions, whose types are both "LOAD". they each have an "Align" field of 0x10000 (64K). This is on my Debian MIPS box.
<mark_weaver>ah, hmm. looking at the "section to segment" mapping, it seems that all the usual important sections (text, data, bss, got, etc) are in those two "LOAD" segments with align 64K.
<mark_weaver>hmm. but how to 'mmap' a file and insure that it is aligned on a 64K boundary, if the runtime page size is less than that?
<mark_weaver>I'm trying to avoid digging into the code of ld.so.
<mark_weaver>ugh, well, I'm going to have to put this hack down for the time being. I need to get tupi's bug fixed.
<dsmith-work>(btw, make ran fine without the -j5)
<civodul>mark_weaver: so, guardians?
<mark_weaver>ah yes!
<civodul>:-)
<mark_weaver>do you see any problem with making guardians thread-safe in the obvious way, by simply putting a mutex in the guardian struct and locking it at the appropriate times? (given that finalizers are now run within asyncs in 2.0)
<mark_weaver>(f740445a9b5bf0a5e5090f0a2ddaffb2b803bab7 is the commit where finalizers were changed to be run during asyncs in 2.0. it uses GC_set_finalizer_notifier)
<mark_weaver>(actually, I think I'll also end up blocking asyncs while the guardian mutex is held, because the guardian needs to be checked from within the after-gc-hook async)
<civodul>lemme check
<mark_weaver>(for that matter, the whole 'cell_pool' hack is probably not necessary either, since that commit)
<civodul>isn't there a possibility for deadlocks?
<mark_weaver>well, that's what I was worried about, of course. but it's not obvious to me how a deadlock could happen here, given that finalizers are run within asyncs now, and the asyncs will be blocked while the mutex is locked.
<civodul>yeah, i was trying to come up with a scenario
<civodul>in master finalize_guarded will be called from another thread, right?
<mark_weaver>yes, I believe so.
<stis>evening folks!
<civodul>hey stis
<civodul>mark_weaver: so it'll have to be thread-safe anywy
<civodul>*anyway
<mark_weaver>right
<civodul>so that's probably the right thing to do?
<mark_weaver>I think so. right now, I can't see how to use guardians safely with the after-gc-hook in a multithreaded program.
<mark_weaver>asyncs are a mess
<mark_weaver>in addition to all this, I also think that we need to block asyncs whenever any of the mutexes that are locked "behind the scenes" by guile during the execution of normal scheme code.
<mark_weaver>are locked..
<mark_weaver>sorry, that was hard to understand, but basically this is needed to allow asyncs to run normal scheme code with deadlocks.
<mark_weaver>*without
<mark_weaver>and moving forward, in master I think we should run the after-gc-hook within another thread, just like we do with finalizers.
<mark_weaver>think about what's needed for (ice-9 popen), which is a very straightforward use of guardians. there's a single guardian that guards all pipes. so that has to be protected with a mutex. since the guardian is also used during the after-gc-hook async, asyncs also have to be blocked whenever the mutex is locked.
<mark_weaver>and then this lead to deadlocks anyway because the VM was locking some internal guile mutex, running asyncs while it was locked, and then trying to lock the same mutex from within the async.
<civodul>yeah, this is all messy
<mark_weaver>meanwhile, tupi recommended the use of guile for process control, and it's all failing because of (ice-9 popen) thread (un)safety. I'm trying to make it work, but that requires fixing this stuff, or at least patching it up.
<mark_weaver>okay, I have to go offline for a bit. if you think of any more ideas or potential problems, please let me know. thanks :)
<civodul>argh
<unknown_lamer>so, I think I might know why telling the incremental collector target < 10ms pauses is not working
<unknown_lamer>the stop function uses two tv.usec values, dividing each by 1000...