Where to find EIO 2.0 implementation

[Robert Withers]

Good afternoon,

I am working on PromisesLocal, found in Cryptography, for Squeak.

Installer ss project: 'Cryptography'; install: 'PromisesLocal'.

I have started working with exceptions to ensure its behavior. I found this EIO page under Concurrency of ELib [1]. This led me to a description of EIO 2.0 [2]. I found E-on-CL [3] but was unable to find an implementation of EIO.

Would someone point me to an EIO impl, please?

Regarding design, is it possible to provide a re-entrant availableReactor, or does each reactor only get activated once? How does it work then? With an EInStream, do we call whenAvailable and with each activation of the availableReactor, recall whenAvailable?

Kindly,
rabbit

[1] EIO - http://www.erights.org/elib/concurrency/eio/index.html

[2] EIO Redesign - http://wiki.erights.org/wiki/EIO_Redesign

[3] E-on-CL - https://github.com/kpreid/e-on-cl

[Kevin Reid]

On Sat, Aug 1, 2020 at 5:54 PM 'Robert Withers' via e-lang <e-l...@googlegroups.com> wrote:

I have started working with exceptions to ensure its behavior. I found this EIO page under Concurrency of ELib [1]. This led me to a description of EIO 2.0 [2]. I found E-on-CL [3] but was unable to find an implementation of EIO.

Would someone point me to an EIO impl, please?

For the version that was actually used in E-on-CL, the interfaces are at

https://github.com/kpreid/e-on-cl/tree/master/lib/org/erights/e/elib/eio

and the concrete streams are at

https://github.com/kpreid/e-on-cl/tree/master/lib/org/cubik/cle/io

Regarding design, is it possible to provide a re-entrant availableReactor, or does each reactor only get activated once? How does it work then? With an EInStream, do we call whenAvailable and with each activation of the availableReactor, recall whenAvailable?

The whenAvailable reactors are part of the oldest design, Version 1 on the wiki page, only. The E-on-CL version, numbered 2 on the wiki page, uses an operation which returns a promise for elements, instead.

(Version 3 with fancy segment/chunk types was never fleshed out enough to be implemented as far as I recall.)

[Robert Withers]

Hi Kevin,

On 8/1/20 9:04 PM, Kevin Reid wrote:

On Sat, Aug 1, 2020 at 5:54 PM 'Robert Withers' via e-lang <e-l...@googlegroups.com> wrote:

I have started working with exceptions to ensure its behavior. I found this EIO page under Concurrency of ELib [1]. This led me to a description of EIO 2.0 [2]. I found E-on-CL [3] but was unable to find an implementation of EIO.

Would someone point me to an EIO impl, please?

For the version that was actually used in E-on-CL, the interfaces are at

https://github.com/kpreid/e-on-cl/tree/master/lib/org/erights/e/elib/eio

and the concrete streams are at

https://github.com/kpreid/e-on-cl/tree/master/lib/org/cubik/cle/io

Thank you for these links. I had looked at the first, but not the second. I will take a closer look.

Regarding design, is it possible to provide a re-entrant availableReactor, or does each reactor only get activated once? How does it work then? With an EInStream, do we call whenAvailable and with each activation of the availableReactor, recall whenAvailable?

The whenAvailable reactors are part of the oldest design, Version 1 on the wiki page, only. The E-on-CL version, numbered 2 on the wiki page, uses an operation which returns a promise for elements, instead.

Alright. I had another project where I was registering reactors that would be sent #value: multiple times. I'll have to go back and think it through again. I guess I want to register a nearRef onto a dispatcher or something, instead. The objective is to register for an event, that may be triggered multiple times.

K, r

(Version 3 with fancy segment/chunk types was never fleshed out enough to be implemented as far as I recall.)

--
You received this message because you are subscribed to the Google Groups "e-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-lang+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/e-lang/CANkSj9Vw%2BCVh-u%2BSNhZD_4frCi5EySUuR7jYgzpUT3jzdaKD1w%40mail.gmail.com.

[Kevin Reid]

On Sun, Aug 2, 2020 at 5:14 AM 'Robert Withers' via e-lang <e-l...@googlegroups.com> wrote:

Alright. I had another project where I was registering reactors that would be sent #value: multiple times. I'll have to go back and think it through again. I guess I want to register a nearRef onto a dispatcher or something, instead. The objective is to register for an event, that may be triggered multiple times.

If you're trying to implement something that meets the same criteria as EIO, I recommend against this. In order to provide both backpressure and the ability to pass an input stream among multiple consumers (e.g. in parsing), it is important that reading some data from an input stream doesn't result in that caller potentially being given an unbounded amount of data at an unexpected future time.

If you're, rather, trying to do some more conventional 'event handling', I do not think EIO has much to teach.

[Robert Withers]

I want both. I want to place an event system as the public api of the EIO. This event system has persistent reactors that get called over and over, so different than a WhenResolvedReactor which only get called once. In my view and in my use of NIO over in Java, I would register an event handler when ever more data arrived from the inStream.

On 8/2/20 9:44 AM, Kevin Reid wrote:

doesn't result in that caller potentially being given an unbounded amount of data at an unexpected future time.

An ability to control QoS of the eventual remote may be able to set a transfer size to limit this. This seems like an environmental issue that needs to be carefully dealt with at runtime. Getting statistics of transfer rates from connections would be helpful in throttling fairly.

Re: source of eventuals

Likewise, a stateful model is a persistent source of events that would be eventualized and called into any event reactors, again. I think the EIO inStream produces near eventual refs. SO I think the core of this event system would be eventuals invoking into handlers. This means both EIO and models are sources of eventuals.

Might EIO work with this? I was thinking a protocol such as #whenAnyResolved: to register a re-entrant reactor on an eventual stream.

K, r

--
You received this message because you are subscribed to the Google Groups "e-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-lang+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/e-lang/CANkSj9W%3DLAq9Bqbft96%3DH%2BjvDH3JOpsybK%2BLDqKDqomsh_X_6Q%40mail.gmail.com.

[Kevin Reid]

On Sun, Aug 2, 2020 at 12:56 PM Robert Withers <robert....@pm.me> wrote:

On 8/2/20 9:44 AM, Kevin Reid wrote:

On Sun, Aug 2, 2020 at 5:14 AM 'Robert Withers' via e-lang <e-l...@googlegroups.com> wrote:

Alright. I had another project where I was registering reactors that would be sent #value: multiple times. I'll have to go back and think it through again. I guess I want to register a nearRef onto a dispatcher or something, instead. The objective is to register for an event, that may be triggered multiple times.

If you're trying to implement something that meets the same criteria as EIO, I recommend against this. In order to provide both backpressure and the ability to pass an input stream among multiple consumers (e.g. in parsing), it is important that reading some data from an input stream doesn't result in that caller potentially being given an unbounded amount of data at an unexpected future time.

If you're, rather, trying to do some more conventional 'event handling', I do not think EIO has much to teach.

I want both. I want to place an event system as the public api of the EIO. This event system has persistent reactors that get called over and over, so different than a WhenResolvedReactor which only get called once. In my view and in my use of NIO over in Java, I would register an event handler when ever more data arrived from the inStream.

I recommend using a different name. "whenResolved" is a name that arises specifically in the context of resolving promises and a promise, by definition, resolves at most once.

An ability to control QoS of the eventual remote may be able to set a transfer size to limit this. This seems like an environmental issue that needs to be carefully dealt with at runtime. Getting statistics of transfer rates from connections would be helpful in throttling fairly.

In an IO API, the goal may not be throttle but rather to consume a specific finite amount of data, such that the next data is known and the stream can be handed off to a different client which expects that input. If you don't need/provide that property and are instead framing it as backpressure on incoming events, then I'd argue you're not actually using an input stream, but rather implementing an output stream (even if it's named differently).

That said, I do think that it would be a plausible but esoteric design choice for an I/O system to avoid having both types of stream objects (which are somewhat redundant) and standardize on one of them. It would just require some thought to ensure that it actually worked well for all necessary cases.

Re: source of eventuals

Likewise, a stateful model is a persistent source of events that would be eventualized and called into any event reactors, again. I think the EIO inStream produces near eventual refs.

Note that "near eventual" is a contradiction in the E reference terminology, if you intended to use it: a reference is either eventual (with subtypes promise (unresolved) or far (resolved)), near, or broken. You could say "a promise which will resolve to a near reference", or you could use the term "vow" which was implemented, somewhat weakly, as a guard in E (accepts promises and near refs but rejects far refs).

SO I think the core of this event system would be eventuals invoking into handlers. This means both EIO and models are sources of eventuals.

Personally I would rather say that an event source is a good candidate for being represented as a stream, but I don't follow all of what you're planning and this might be a reasonable plan.

Might EIO work with this? I was thinking a protocol such as #whenAnyResolved: to register a re-entrant reactor on an eventual stream.

As I said above, please do not use the "whenResolved" name or anything similar to be about streams, events, or anything that fires repeatedly with new data. It will create confusion with how promises work.

[Robert Withers]

On 8/2/20 4:55 PM, Kevin Reid wrote:

On Sun, Aug 2, 2020 at 12:56 PM Robert Withers <robert....@pm.me> wrote:

On 8/2/20 9:44 AM, Kevin Reid wrote:

On Sun, Aug 2, 2020 at 5:14 AM 'Robert Withers' via e-lang <e-l...@googlegroups.com> wrote:

Alright. I had another project where I was registering reactors that would be sent #value: multiple times. I'll have to go back and think it through again. I guess I want to register a nearRef onto a dispatcher or something, instead. The objective is to register for an event, that may be triggered multiple times.

If you're trying to implement something that meets the same criteria as EIO, I recommend against this. In order to provide both backpressure and the ability to pass an input stream among multiple consumers (e.g. in parsing), it is important that reading some data from an input stream doesn't result in that caller potentially being given an unbounded amount of data at an unexpected future time.

If you're, rather, trying to do some more conventional 'event handling', I do not think EIO has much to teach.

I want both. I want to place an event system as the public api of the EIO. This event system has persistent reactors that get called over and over, so different than a WhenResolvedReactor which only get called once. In my view and in my use of NIO over in Java, I would register an event handler when ever more data arrived from the inStream.

I recommend using a different name. "whenResolved" is a name that arises specifically in the context of resolving promises and a promise, by definition, resolves at most once.

An ability to control QoS of the eventual remote may be able to set a transfer size to limit this. This seems like an environmental issue that needs to be carefully dealt with at runtime. Getting statistics of transfer rates from connections would be helpful in throttling fairly.

In an IO API, the goal may not be throttle but rather to consume a specific finite amount of data, such that the next data is known and the stream can be handed off to a different client which expects that input. If you don't need/provide that property and are instead framing it as backpressure on incoming events, then I'd argue you're not actually using an input stream, but rather implementing an output stream (even if it's named differently).

Yes, that is precisely how my ASN1InputStream decodes bytes. This reading has an imperative flavor. Read, read, ... Yet this may be triggered by an event handler, such that the event source, be it stream or fd or model, pressurizes. This is a design principle to result in a reactive system. Pressurized yet self-descriptive and careful on consuming.

That said, I do think that it would be a plausible but esoteric design choice for an I/O system to avoid having both types of stream objects (which are somewhat redundant) and standardize on one of them. It would just require some thought to ensure that it actually worked well for all necessary cases.

Re: source of eventuals

Likewise, a stateful model is a persistent source of events that would be eventualized and called into any event reactors, again. I think the EIO inStream produces near eventual refs.

Note that "near eventual" is a contradiction in the E reference terminology, if you intended to use it: a reference is either eventual (with subtypes promise (unresolved) or far (resolved)), near, or broken. You could say "a promise which will resolve to a near reference", or you could use the term "vow" which was implemented, somewhat weakly, as a guard in E (accepts promises and near refs but rejects far refs).

I see. I have a near ref which is #eventual, produces promises when sent a message.

((10 eventual factorial / 100) * 25) whenResolved: [:i | i value].

SO I think the core of this event system would be eventuals invoking into handlers. This means both EIO and models are sources of eventuals.

Personally I would rather say that an event source is a good candidate for being represented as a stream, but I don't follow all of what you're planning and this might be a reasonable plan.

The uniqueness of an eventful model is that the events are signposts to state changes and thus there are a variety of event types, specified by a symbol, in Squeak.

Might EIO work with this? I was thinking a protocol such as #whenAnyResolved: to register a re-entrant reactor on an eventual stream.

As I said above, please do not use the "whenResolved" name or anything similar to be about streams, events, or anything that fires repeatedly with new data. It will create confusion with how promises work.

The Squeak protocol, in base system, for registering an event handler is #when:send:to:with:... so the #when semantic is appropriate, I feel. The #Resolved part is Eventual in nature and resolves once. I see this. So I would suggest #whenAvailable: or #whenEventProduced: or some such...

K, r

--
You received this message because you are subscribed to the Google Groups "e-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-lang+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/e-lang/CANkSj9XXgGXmfZ7RT3pWVphUO92TH8%2BuCABZ3ZKekJvXW58dLw%40mail.gmail.com.