Pass timeout parameter

Question

Pass timeout parameter

my-flow opened this issue 9 years ago · comments

Hi Saša,

Thank you for this great library! I'm using it in multiple projects already.

What's the best way to pass a user-defined timeout parameter if the call is not made from another ExActor (where I could use timeout_after(:timer.seconds(10))), but from somewhere else?

Currently I have to fall back to the original GenServer implementation of Elixir and cannot use the ExActor API when making a call with a custom timeout. Example:

{:ok, pid} = CSVImporter.start_link
GenServer.call(pid, {:import, path}, :infinity)

What I would prefer is something like this:

{:ok, pid} = CSVImporter.start_link
CSVImporter.import(pid, path, :infinity)

The last parameter is currently not handled as a separate timeout parameter, but translated to CSVImporter.import(pid, path, :infinity) which is not what I want. Is there a way to make timeout calls using the ExActor API?

Thanks,
Florian

Saša Jurić · Answer 1 · Mon Mar 23 2015 03:48:30 GMT+0800 (China Standard Time)

Hi Florian, and thank you for the feedback. It's nice to learn that the library is being used :-)

Yes, this is indeed a shortcoming currently. I'm also facing it in my own library, as can be seen for example here.

I have in fact developed a fix for this a few months ago, but due to some sidetrack (mostly the work on the book) I didn't publish it yet. I just pushed those commits to the 2.1.0 branch. You can see the doc here. Please let me know if this would suit your needs.

I'd still like to sleep on this. The timeout fix seems fine to me, but in the process I also discovered another bug, which causes a slight change in the interface. See breaking changes section in the changelog.

I'm mostly leaning towards publishing this, but if you have some comment, now is the good time to share it :-)

my-flow · Answer 2 · Mon Mar 23 2015 05:16:26 GMT+0800 (China Standard Time)

The parameterizable timeout fix is exactly what I was looking for and would certainly solve my “problem” ;-)

However, I also noticed the breaking changes that 2.1.0 brings and I would argue that it makes using ExActor more difficult. Pattern-matching on the state of an actor is quite a powerful language feature and I would prefer if ExActor created the headless interface function specification automagically in the background.

Saša Jurić · Answer 3 · Mon Mar 23 2015 06:11:44 GMT+0800 (China Standard Time)

Thank you for the comment. I have cherry picked only the timeout improvement, and pushed 2.1.0 (also available on hex). Let me know if this works for you.

Pattern matching on the state currently works by chance, but as the consequence, documentation source links for client libraries are not properly generated. I'll leave the doc bug as it is for the moment, and try to see how can I resolve it without breaking state pattern matching.

We're hitting some limitations here, since defcall should define two functions, and we need to decide whether an interface function needs to be generated based on the pattern. I need to think about this problem some more, and see what can be done about it.