Yes. I'm sure both you and Mark can judge this better than can, currently.
I just didn't think Guile was that thread-unsafe. I imagined you would have to use mutexes around some I/O and common datastructures, and that that would be about it, but I'm probably wrong... Best regards, Mikael On Wed, Nov 18, 2015 at 3:16 PM, Christopher Allan Webber <cweb...@dustycloud.org> wrote: > Mikael Djurfeldt writes: > >> Den 4 okt 2015 02:30 skrev "Christopher Allan Webber" < >> cweb...@dustycloud.org>: >>> - This would be like asyncio or node.js, asynchronous but *not* OS >>> thread based (it's too much work to make much of Guile fit around >>> that for now) >> >> Why is this (too much work for threads)? > > Threads bring a lot of risky problems. I really don't want to deal with > that much locking. A lot of Guile's code isn't thread-safe... if we > wanted to go to the "oh yeah super safe with threads!" direction, > it might require something like Clojure's software transactional > memory. I talked to Mark Weaver about this; it's very expensive to do, > super hard to implement (I don't think we have any guile devs > interested), and makes things slower whenever you *aren't* using > threads. > > The asyncio / node.js style of things can solve IO bound problems. As > for CPU bound, we can use message passing between threads or processes. > > It's beneficial to focus on message passing for CPU bound issues anyway, > because this means that our code will be able to span across machines, > if said messages are serializable. > > Does that make sense? > - Chris
