Re: anyone define port types?

[Andy Wingo <wingo@pobox.com>]

On Thu 23 Jun 2016 11:24, Chris Vine <chris@cvine.freeserve.co.uk> 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.

Yep!

> 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 :/

Andy