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

[Exploration] Enrich the return value of DSL handlers #2

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

xosmig
Copy link
Owner

@xosmig xosmig commented Aug 12, 2022

Through the return value, the handler can:

  1. return an error
  2. pass the information that the event doesn't match the handler
  3. inform the dsl core that the handler should be unregistered
    and should never be repeated again.

The main motivation behind this is to dynamically register
handlers within other handlers (to avoid running out of memory,
this implies the need to unregister handlers).

However, the problem is that dynamically creating a large number
of handlers would not play well with the current appoach of
trying "searching" for the right handler by trying all handlers
for the event type. Indeed, the linear search may be too slow and
wasteful.

There was also a problem with the NoMatch() return value. The
problem is that it is not always trivial to choose between
NoMatch() and OK(). Moreover, sometimes it can lead to potential
vulnerabilities: e.g., if there is an incoming nonsense message
and all message handlers return NoMatch(), the module may return
an error and crash.

Through the return value, the handler can:
1) return an error
2) pass the information that the event doesn't match the handler
3) inform the dsl core that the handler should be unregistered
   and should never be repeated again.

The main motivation behind this is to dynamically register
handlers within other handlers (to avoid running out of memory,
this implies the need to unregister handlers).

However, the problem is that dynamically creating a large number
of handlers would not play well with the current appoach of
trying "searching" for the right handler by trying all handlers
for the event type. Indeed, the linear search may be too slow and
wasteful.

There was also a problem with the NoMatch() return value. The
problem is that it is not always trivial to choose between
NoMatch() and OK(). Moreover, sometimes it can lead to potential
vulnerabilities: e.g., if there is an incoming nonsense message
and all message handlers return NoMatch(), the module may return
an error and crash.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant