Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Two working implementations #124

Open
kelunik opened this issue Dec 29, 2016 · 10 comments
Open

Two working implementations #124

kelunik opened this issue Dec 29, 2016 · 10 comments
Milestone

Comments

@kelunik
Copy link
Member

kelunik commented Dec 29, 2016

Following the FIG, I think it's good to have two working implementations passing all tests. I think we should have v0.4.0 and two working implementations, then tag v1.0.0.

@kelunik kelunik modified the milestone: 1.0.0 Dec 29, 2016
@bwoebi
Copy link
Member

bwoebi commented Dec 29, 2016

AFAIK we have a working implementation by @martinschroeder: koolkode/async: https://github.com/koolkode/async
And our own, amp/loop: https://github.com/amphp/loop

which each pass all tests by their currently supported loops.

@kelunik
Copy link
Member Author

kelunik commented Dec 29, 2016

@bwoebi We need tests for strict types. koolkode/async uses strict types currently.

@bwoebi
Copy link
Member

bwoebi commented Dec 29, 2016

Yeah, that has been changed very recently, will add a test to event-loop-test repo

@bwoebi
Copy link
Member

bwoebi commented Dec 29, 2016

Test added \cc @martinschroeder

@kelunik
Copy link
Member Author

kelunik commented Dec 29, 2016

@bwoebi There's a typo in your ping.

I just tagged v0.4.0, so implementations can depend on that. I guess we will have a tag for the tests soon.

https://github.com/async-interop/event-loop/releases/tag/v0.4.0

@ghost
Copy link

ghost commented Dec 29, 2016

Thanks for letting me know. I removed strict types from the loop implementations and will have a look into version 0.4 of the loop spec today or maybe tomorrow.

I had to disable the test case for nested loop signal dispatching for the event extension due to an issiue with epoll. All other test cases are working out fine. My question is: Does the loop implementation still conform to the specification or do i have to remove the entire signal handling support from the event-extension-based loop?

@bwoebi
Copy link
Member

bwoebi commented Dec 29, 2016

@martinschroeder I wonder, is there no workaround?

a) You could shut the warning up with @ and enable/disable the signal watchers when Driver::run() is entered/left (so that always the signal handler of the previous loop is taking priority if there was one)
b) you could fall back to pcntl signals [ :-( ]

@ghost
Copy link

ghost commented Dec 29, 2016

@bwoebi I will have a look into the enable/disable solution tomorrow, sounds like a good idea to me.

@AndrewCarterUK
Copy link
Contributor

I think working on consumers is as important, if not more, than working on implementations. The best approach from here would be refactoring a collection of async PHP apps to use this event loop.

I've got a PHP snake game that uses React which I can try to rewrite - but I am incredibly limited on time at the moment!

@ghost
Copy link

ghost commented Dec 30, 2016

I migrated koolkode/async to event loop API version 0.4 and tagged a new release 0.2.10 that provides the event loop implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants