-
Notifications
You must be signed in to change notification settings - Fork 824
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
Ability to detect a tainted instance #4220
Conversation
- When registering a handler twice it would fail the second time - DONTROUTE was being set which basically breaks all networking - Poll was registered on the wrong events (this was introduced in this patch earlier rather than from mainline) - The writable event was being triggered at the wrong time (i.e. either too early or two late) - converted to a non-blocking poll call instead - Added a unit test so that this doesn't happen again
… compiler version
- Fixed the windows build issues - Fixed some linting errors - Fixed some epoll backwards compatible issues - Implemented a unit tests for epoll to google
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll generally want to share a Runtime
to reuse the same thread pool, any connections that may still be held open by the HTTP client, in-memory caches, and so on.
With that in mind, I think we need to include some sort of ID (or a reference to the wasmer::Instance
) in on_taint()
that allows the runtime to know which instance became tainted. Otherwise we've just got a "something went wrong" callback and the only way to know which instance became tainted is through context, which is pretty brittle.
We'll keep this open for now, but ideally we should use proper signal propagation to implement this properly (based on @theduke feedback) |
Rebase failed
This needs to go in first
#4211