Re: anyone define port types?

[Andy Wingo <wingo@pobox.com>]

On Fri 01 Apr 2016 16:38, ludo@gnu.org (Ludovic Courtès) writes:

> Here’s a port type!  :-)
>
>   https://gitlab.com/gnutls/gnutls/blob/master/guile/src/core.c#L785

Thanks!

So port types written in C will have to change unfortunately :/  From
NEWS:

    ** Complete overhaul of port internals

    Guile's ports have been completely overhauled to allow Guile developers
    and eventually Guile users to write low-level input and output routines
    in Scheme.  The new internals will eventually allow for user-space
    tasklets or green threads that suspend to a scheduler when they would
    cause blocking I/O, allowing users to write straightforward network
    services that parse their input and send their output as if it were
    blocking, while under the hood Guile can multiplex many active
    connections at once.

    At the same time, this change makes Guile's ports implementation much
    more maintainable, rationalizing the many legacy port internals and
    making sure that the abstractions between the user, Guile's core ports
    facility, and the port implementations result in a system that is as
    performant and expressive as possible.

    The interface to the user has no significant change, neither on the C
    side nor on the Scheme side.  However this refactoring has changed the
    interface to the port implementor in an incompatible way.  See below for
    full details.

And later:

    ** API to define new port types from C has changed

    See the newly expanded "I/O Extensions" in the manual, for full details.
    Notably:

    *** Remove `scm_set_port_mark'

    Port mark functions have not been called since the switch to the BDW
    garbage collector.

    *** Remove `scm_set_port_equalp'

    Likewise port equal functions weren't being called.  Given that ports
    have their own internal buffers, it doesn't make sense to hook them into
    equal? anyway.

    *** Remove `scm_set_port_free'

    It used to be that if an open port became unreachable, a special "free"
    function would be called instead of the "close" function.  Now that the
    BDW-GC collector allows us to run arbitrary code in finalizers, we can
    simplify to just call "close" on the port and remove the separate free
    functions.  Note that hooking into the garbage collector has some
    overhead.  For that reason Guile exposes a new interface,
    `scm_set_port_needs_close_on_gc', allowing port implementations to
    indicate to Guile whether they need closing on GC or not.

    *** Remove `scm_set_port_end_input', `scm_set_port_flush'

    As buffering is handled by Guile itself, these functions which were to
    manage an implementation-side buffer are no longer needed.

    *** Change prototype of `scm_make_port_type'

    The `read' (renamed from `fill_input') and `write' functions now operate
    on bytevectors.  Also the `mode_bits' argument now inplicitly includes
    SCM_OPN, so you don't need to include these.

    *** Change prototype of port `close' function

    The port close function now returns void.

    *** Port and port type data structures are now opaque

    Port type implementations should now use API to access port state.
    However, since the change to handle port buffering centrally, port type
    implementations rarely need to access unrelated port state.

    *** Port types are now `scm_t_port_type*', not a tc16 value

    `scm_make_port_type' now returns an opaque pointer, not a tc16.
    Relatedly, the limitation that there only be 256 port types has been
    lifted.

Now.  How to adapt?  You can do the #if thing with versions.  Or, maybe
we should flesh out the custom binary input/output port support so that
you can implement a GnuTLS port in Scheme.  WDYT?

Andy