[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: anyone define port types?

From: Andy Wingo
Subject: Re: anyone define port types?
Date: Thu, 23 Jun 2016 12:43:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

On Thu 23 Jun 2016 11:24, Chris Vine <address@hidden> writes:

> A few things on that.  First, there will always be a use for an event
> loop to do event-loopy things, irrespective of whether and how a
> coroutine interface is put around it.  Sometimes you want to abstract
> things away, sometimes you don't.


> Secondly, as I understand it in the end you want pre-emptive "green"
> threads for guile, whereas my code equates to co-operative
> multi-tasking, whilst also working with native threads.  I must come
> clean and say that I don't like "green" threads.

I actually don't want *pre-emptive* threads -- I'd rather have threads
suspend at I/O points instead.  But yeah, my preferred abstraction is
threads; and those user-space threads could be bound to a core, or we
could schedule them on multiple cores.  But there's room for many things

> Which leads on to the third point, which is that I would like to see
> guile match its words (in its documentation) with respect to native
> threads.  I have found they work fine, with caution about shared global
> state.  You think they don't, except possibly on intel, because some of
> its lock-free structures/variables -- and I think you are possibly
> referring to the VM here -- lack appropriate fences or other atomics.
> (The higher level C and scheme code has plainly had serious attempts at
> thread-safety made for it using mutexes.)

I see what you mean.  On the other hand I don't like documenting bugs :/
(I prefer to fix them, and find that often the effort is similar.)  Good
native thread support is within Guile's remit and everyone should have
the good experience that you have had.  But that's not something we can
guarantee right now unfortunately :/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]