[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Asynchronous event loop brainstorm at FSF 30
From: |
Mikael Djurfeldt |
Subject: |
Re: Asynchronous event loop brainstorm at FSF 30 |
Date: |
Wed, 18 Nov 2015 17:36:57 +0100 |
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
<address@hidden> wrote:
> Mikael Djurfeldt writes:
>
>> Den 4 okt 2015 02:30 skrev "Christopher Allan Webber" <
>> address@hidden>:
>>> - 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