Scoping the Event Loop PSR Proposal

[Andrew Carter]

Hello All,

I've set up an organisation for the event loop PSR proposal on GitHub (https://github.com/event-loop-proposal)

This houses a fork of the fig standards repository (https://github.com/event-loop-proposal/fig-standards) which has a few words to form the basis for an entrance vote.

In this thread I'd like to request the involvement of anyone with an interest in this PSR, particularly the new (and soon to be new) async member projects. I think it would be good to start a high level discussion about what we hope to achieve with this PSR and why we think it's necessary. From this discussion I/we will draft an entrance proposal.

I'd like to encourage pull requests to the repository from those who wish to get involved. Once we've sorted out the roles for this proposal, I'll dish out merge access to the organisation and we can have a rule of not merging your own pull requests.

Very interested to hear your thoughts!

Andrew

[Andrew Carter]

To start us off:

I'd like this proposal to open the door to creating PHP applications where all the I/O can be non-blocking on a single event loop. Whilst an event loop is a core component to Javascript engines, in PHP we need to either couple to an async library or implement our own (e.g. by using select() or stream_select()).

A standard set of interfaces would allow for a whole range of packages, adapters and servers to be created independent from the underlying implementation of the event loop. I believe that the requirement to couple to projects that are often young and unstable is a huge limiting factor in the world of async PHP. I would suggest that PSR's such as this would help to change this.

[Niklas Keller]

Wouldn't a single interface be enough? I don't think we need a whole set of interfaces just for the loop.

Amp example: https://github.com/amphp/amp/blob/master/lib/Reactor.php

[Andrew Carter]

@Niklas

I think a single interface would be possible if using stream socket resources (as the AMPHP example shows). Most implementations that I've seen actually wrap I/O streams in a class and this would require a more descriptive specification and introduces a couple of other considerations.

I'd like to reword my statement to say that I think standardisation in general would help. My intention to start a discussion on what we'd like the PSR to achieve rather than suggest implementation details - apologies!

[Niklas Keller]

Just a further note: If we choose to wrap I/O streams, I think we need a Stream PSR first. And a Stream PSR would probably depend on a Promise PSR. Unfortunately, we already mixed some stream interface into PSR-7.

Am Mittwoch, 25. November 2015 13:59:44 UTC+1 schrieb Andrew Carter:

@Niklas

I think a single interface would be possible if using stream socket resources (as the AMPHP example shows). Most implementations that I've seen actually wrap I/O streams in a class and this would require a more descriptive specification and introduces a couple of other considerations.

I'd like to reword my statement to say that I think standardisation in general would help. My intention to start a discussion on what we'd like the PSR to achieve rather than suggest implementation details - apologies!

Sure, standardization will help, help a lot. Fine. 

[Andrew Carter]

Event loop features and implementation status amongst major projects:

• I/O streams
  Supported by: amp, React, Icicle
  
  
• Signals
  Supported by: amp, Icicle
  
  
• Timers (One off and periodic)
  Supported by: amp, React, Icicle
  
  
• Deferred Execution
  Supported by: amp, React, Icicle

Not sure if anybody knows of any other projects or features to add to this list.

Interested to hear opinions on what should and shouldn't be included.

[Cees-Jan Kiewiet]

There is a 3rd party package to do signals in react.

As for the I/O streams not all streams you register are I/O streams in the general sense. For example look at eio_get_event_stream, it notifies the listener that something from an EIO thread is ready to be handled but you don't read/write data to/from it. The event loop handles ready to read or/and write notifications from resources, the reading/writing is done somewhere else.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/a125991a-63ab-49a4-b63c-53281bc49ebb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Niklas Keller]

How about coroutines? They're coupled to the loop in some implementations. Amp has them, Icicle has them and there's a package for React: https://github.com/recoilphp/recoil

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAPY1sU_bdOeXm7xhBbdLQ7DWQ7pskK3maWdmc0Ygkb%2BFhWdDzQ%40mail.gmail.com.

[Cees-Jan Kiewiet]

Yes but from what I can see, and correct me if I'm wrong here, they don't tie directly into the event loop the way resources, timers, and deferred execution do. Which brings me to the questions what do we want in this PSR, is that just an event loop interface or do we want to include more like coroutines, streams interfaces, timer interface(s)?

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANUQDCg_i0mKEQdXBOH7bxpP%2B4G7ncTQ4p7fec4vk4KDnkPNDg%40mail.gmail.com.

[Andrew Carter]

I think another stream interface is not a great idea.

I've tried to open discussion on a stream PSR in a new thread: https://groups.google.com/forum/#!topic/php-fig/LGYQ5x9L9-k

[Niklas Keller]

I think another stream interface is not a great idea.

I've tried to open discussion on a stream PSR in a new thread: https://groups.google.com/forum/#!topic/php-fig/LGYQ5x9L9-k

I know that another one is not great, but the current one just doesn't work with async, see things like __toString. 

[Niklas Keller]

Yes but from what I can see, and correct me if I'm wrong here, they don't tie directly into the event loop the way resources, timers, and deferred execution do. Which brings me to the questions what do we want in this PSR, is that just an event loop interface or do we want to include more like coroutines, streams interfaces, timer interface(s)?

 Just wrote a small amp script to verify:

<?php

require "vendor/autoload.php";

Amp\run(function() {

        $callable = function(): Generator {

                yield new Amp\Pause(10000);

                return true;

        };

        $coroutine = Amp\coroutine($callable);

        $coroutine();

});

Coroutines are active watchers and as long as active watchers exist, the event loop keeps running in amp.

[Andrew Carter]

It might be unwise to use the __toString() method in an async environment but I don't think that it wouldn't work as such.

Wouldn't it be a better idea to improve the proposal so that it makes clear blocking and non blocking methods and is more suable in an async environment?

[Niklas Keller]

It might be unwise to use the __toString() method in an async environment but I don't think that it wouldn't work as such.

It might not only be unwise, but depending on the implementation even not possible.

 

Wouldn't it be a better idea to improve the proposal so that it makes clear blocking and non blocking methods and is more suable in an async environment?

Having a common interface for sync and async doesn't make sense to me. 

[Andrew Carter]

Even if the decision is to separate the two interfaces they would likely be contained in the same proposal.

Would you see one as an extension of the other or both as completely separate?

[Niklas Keller]

Even if the decision is to separate the two interfaces they would likely be contained in the same proposal.

Would you see one as an extension of the other or both as completely separate?

Personally, I'd like to have only an async one and let the applications then use some waiting on the promise resolution mechanism, but that's somehow ugly again for applications doing everything the traditional synchronous way, because the would have to deal with promises then. On the other hand, this would enable them to combine these waits and more libraries would be usable in an async world.

[Cees-Jan Kiewiet]

Makes sense as it looks like coroutines are using the deferred execution of callbacks within the event loop. Which makes them like streams vs. resources. One is low level within the event loop and the other builds on that low level functionality of the event loop. Coroutines have no doubt a place within this PSR, but I doubt it is in the event loop interface. But maybe we're getting in to much technical details :).

Been at __toString()/getContent() and done them async, it's horrible, with the PSR7 interface, as you have to tick the loop until they are done. Promises could be a solution but imho that is a buffered sink's job not the stream it self. Common interfaces for sync and async are a bad idea.

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5b9ff364-5396-4a21-ad85-9b4687807da0%40googlegroups.com.

[Jeremy Lindblom]

Do Observables, pitched by Chris Boden during a Promises discussion, have a place here? Aren't they basically a type of async stream?

--

Jeremy Lindblom (@jeremeamia)

Software Engineer at Engrade

McGraw-Hill Education

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAPY1sU8SJmT7eRttJaiuumbqvuKrFwTxL_vNx%2B1icF1_GJz%2BhA%40mail.gmail.com.

[Larry Garfield]

I think that depends on whether you're talking about a byte stream, a
producer-of-structured-objects (an inside out iterator, essentially), or
both. I don't know this space well enough to know if merging those into
a single interface makes sense or not.

On 11/25/15 10:13 AM, Jeremy Lindblom wrote:
> Do Observables, pitched by Chris Boden during a Promises discussion,
> have a place here? Aren't they basically a type of async stream?
>
> --
> Jeremy Lindblom (@jeremeamia)
> Software Engineer at Engrade
> McGraw-Hill Education
>
>
>
> On Nov 25, 2015, at 7:49 AM, Cees-Jan Kiewiet <cees...@gmail.com

>> <mailto:php-fig+u...@googlegroups.com>.

>> To post to this group, send email to php...@googlegroups.com

>> <mailto:php...@googlegroups.com>.

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/php-fig/5b9ff364-5396-4a21-ad85-9b4687807da0%40googlegroups.com

>> <https://groups.google.com/d/msgid/php-fig/5b9ff364-5396-4a21-ad85-9b4687807da0%40googlegroups.com?utm_medium=email&utm_source=footer>.

>>
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "PHP Framework Interoperability Group" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to php-fig+u...@googlegroups.com

>> <mailto:php-fig+u...@googlegroups.com>.

>> To post to this group, send email to php...@googlegroups.com

>> <mailto:php...@googlegroups.com>.

>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/php-fig/CAPY1sU8SJmT7eRttJaiuumbqvuKrFwTxL_vNx%2B1icF1_GJz%2BhA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/php-fig/CAPY1sU8SJmT7eRttJaiuumbqvuKrFwTxL_vNx%2B1icF1_GJz%2BhA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>> For more options, visit https://groups.google.com/d/optout.
> --
> You received this message because you are subscribed to the Google
> Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to php-fig+u...@googlegroups.com

> <mailto:php-fig+u...@googlegroups.com>.

> To post to this group, send email to php...@googlegroups.com

> <mailto:php...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/F78EE280-099C-457C-8D6E-2FB7C6D354D3%40gmail.com
> <https://groups.google.com/d/msgid/php-fig/F78EE280-099C-457C-8D6E-2FB7C6D354D3%40gmail.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

--

--Larry Garfield

[Aaron Piotrowski]

There's no reason to have a stream interface in an event loop PSR. An event loop should only provide notifications when a descriptor is ready for reading or has space to write. You can use these notifications to create an async stream object (see https://github.com/icicleio/stream), but this is separate from the event loop.

There's a couple of ways watchers can be approached: Icicle returns objects from methods that are used to start/stop/ watchers. Amp returns IDs that can be passed to loop methods to start/stop the watcher. Either method has pros and cons, so I'm not sure which would be appropriate for a PSR.

Coroutines also have no place in the event loop PSR. Coroutines are dependent on some sort of watcher to resolve the promise/future/awaitable to continue execution.

Things an event loop should be able to do:

Poll stream sockets for available data/space to write

Run timers (single and periodic)

Listen for signals (which may be disabled if pcntl or other signal handling mechanism is not available)

Defer execution (delaying execution of a function until the stack is clear is sometimes necessary, see the queue() method in https://github.com/icicleio/icicle/blob/master/src/Loop/Loop.php)

I think Icicle's event loop is close to what a minimal event loop should look like (though even Icicle's loop has some methods that would not be necessary for a PSR event loop).

[Cees-Jan Kiewiet]

Tbh I'm torn between using objects or IDs for watchers. IDs allow for a really simple PSR but objects give us more room to create a well thought out API. While react (un)regisers what ever resource/timer you give it. Not  sure which is best but imho a clean and simple API would be the best.

Agreed on the list of things an event loop should do. And tbh React/amphp/Icicle already have very minimal event loops with barely to no bloat. Among the differences between loopt I find amphp's info method interesting: https://github.com/amphp/amp/blob/master/lib/Reactor.php#L138-L160 it gives an insight into the store of the event loop but should be no means be a performance degradation for the loop.

Looking a head a bit but aside from a promise PSR a stream PSR isn't a bad plan at all.

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/6b5f148c-befc-439d-8b5c-064c5f3e303a%40googlegroups.com.

[Andrew Carter]

Cees-Jan,

Would you like to be involved in a Stream PSR?

I've made whispers about it in this thread: https://groups.google.com/forum/#!topic/php-fig/LGYQ5x9L9-k

The proposal would need a sponsor, a co-ordinator and an editor. I'm happy to put myself forward as editor again (it's all I can do as a non-voting member), but obviously this would delay the event loop PSR so I would rather not.

Best Regards,

Andrew

[Cees-Jan Kiewiet]

Hey Andrew,

I'm interested but prefer to focus on the event loop first and get it in a more concrete state. Want have some experience working on PSRs before starting another one :).

Cees-Jan

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/68939981-3aea-47ab-bbb7-03d69f494d89%40googlegroups.com.