Re: Asynchronous event loop brainstorm at FSF 30

[Mikael Djurfeldt]

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