Re: 01/02: Re-implement (ice-9 streams) in terms of (srfi srfi-41)

Re: 01/02: Re-implement (ice-9 streams) in terms of (srfi srfi-41)

[Mark H Weaver]

Andy Wingo <wingo@pobox.com> writes:

> wingo pushed a commit to branch master
> in repository guile.
>
> commit aead655a45e689b332cfd148ecbb6d764e2c8eb8
> Author: Andy Wingo <wingo-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
> Date:   Thu Mar 5 09:44:53 2015 +0100
>
>     Re-implement (ice-9 streams) in terms of (srfi srfi-41)
>     
>     * module/ice-9/streams.scm: Re-implement in terms of SRFI-41.  Passes
>       tests.

I think we can't do this because (ice-9 streams) are based on native
Guile promises which provide built-in thread synchronization, whereas
SRFI-41 streams are based on SRFI-45 promises which do not include
thread synchronization.

I vaguely remember finding that SRFI-45 promises (written in pure
Scheme) performed better than native Guile promises (written in C),
presumably because of the lack of built-in thread synchronization.  I
don't remember what platform I did those comparisons on.

     Mark

Re: 01/02: Re-implement (ice-9 streams) in terms of (srfi srfi-41)

[Andy Wingo]

Hi!

Sorry, I tried to grab you by chat but I think we missed each other.

On Wed 11 Mar 2015 03:58, Mark H Weaver <mhw@netris.org> writes:

>> commit aead655a45e689b332cfd148ecbb6d764e2c8eb8
>> Author: Andy Wingo <wingo-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
>> Date:   Thu Mar 5 09:44:53 2015 +0100
>>
>>     Re-implement (ice-9 streams) in terms of (srfi srfi-41)
>>     
>>     * module/ice-9/streams.scm: Re-implement in terms of SRFI-41.  Passes
>>       tests.
>
> I think we can't do this because (ice-9 streams) are based on native
> Guile promises which provide built-in thread synchronization, whereas
> SRFI-41 streams are based on SRFI-45 promises which do not include
> thread synchronization.

Interesting, this isn't the objection I thought you might have :)

The motivating case is GDB, that because it supports guile before 2.0.9
that we can't use the excellent SRFI-41 streams there.  On the other
hand that's terrible to add new users to ice-9 streams, and indeed
terrible in Guile to have two disjoint lazy stream types.  (Perhaps this
is another problem that could be solved with polymorphism?  Dunno.)
Since GDB will expose streams in its interface, that means more and more
users of ice-9 streams, yuck.  `make-stream' is terrible.

Anyway reimplementing ice-9 streams in terms of srfi-41 provides a
migration path away from ice-9 streams, such that we can deprecate the
module and hopefully remove it some time.  I think you probably agree
that would be nice to do if we can manage it.

So, the question is -- is there a level of legacy fidelity of an
ice-9-streams-on-top-of-srfi-41 that would allow us to make this change?
Is it "identical" or is "pretty close" sufficient?  I submit that
"pretty close" is OK, for some definitions of pretty close, as long as
the changes are documented in NEWS.

So, what if we just document this change?  We could roll it back of
course but blah, srfi-41 is so much nicer.

Andy
-- 
http://wingolog.org/

Re: 01/02: Re-implement (ice-9 streams) in terms of (srfi srfi-41)

[Ludovic Courtès]

Perhaps the right thing would be to just fix SRFI-45 promises to be
thread-safe, no?

Ludo’.

Re: 01/02: Re-implement (ice-9 streams) in terms of (srfi srfi-41)

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Perhaps the right thing would be to just fix SRFI-45 promises to be
> thread-safe, no?

This would slow down the fastest implementation of promises we could
hope for by an order of magnitude, at least on non-Intel platforms.

This in turn would severely limit the set of applications for which
SRFI-45 promises and SRFI-41 streams would be efficient enough to
consider.

If most of the Guile community wants to persue this strategy of building
thread synchronization into primitives that could otherwise be extremely
cheap, then I'd better withdraw from this community.

     Mark

Re: 01/02: Re-implement (ice-9 streams) in terms of (srfi srfi-41)

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Perhaps the right thing would be to just fix SRFI-45 promises to be
>> thread-safe, no?
>
> This would slow down the fastest implementation of promises we could
> hope for by an order of magnitude, at least on non-Intel platforms.
>
> This in turn would severely limit the set of applications for which
> SRFI-45 promises and SRFI-41 streams would be efficient enough to
> consider.

Good point.

The other side of the problem is that non-thread-safe promises also
limit the set of contexts they can be used in.  (I remember relying on
the fact that core promises were thread-safe quite a few times.)

Anyway, I withdraw my suggestion.

BTW, I just realized that core promises use fat mutexes, which is
unfortunate.  Using plain pthread mutexes would make them faster, and
costing nothing in single-threaded programs on glibc systems.  Perhaps
that’s something we should try?

> If most of the Guile community wants to persue this strategy of building
> thread synchronization into primitives that could otherwise be extremely
> cheap, then I'd better withdraw from this community.

Mark, please let’s assume good faith and avoid gratuitous confrontation.
Clearly, in this case, we are focusing on different concerns of the
matter, and that is fine.

Last month Andy attempted to start the port thread-safety discussion
again explicitly asking for your feedback, and thinking about ways to
move forward:
<http://lists.gnu.org/archive/html/guile-devel/2015-02/msg00010.html>.
I think there’s a chance we could take into account both the concerns
that Andy raised and those that you raised, so let’s not miss it.

Thanks,
Ludo’.