<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 04/10/2014 05:02 PM, Dmitry
Demeshchuk wrote:<br>
</div>
<blockquote
cite="mid:CANH2pzsHTGtvG-bQB7T4yfyb=rzCzymhrNuwjQfh=A-cyHXKeQ@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi list,
<div><br>
</div>
<div>Today (yeah, just a couple years have passed since R14A) I
learned about OTP-8623, which allows to do selective receive
for messages that contain a known reference with O(1)
complexity.</div>
<div><br>
</div>
<div>Which made me think: what if we make a gen_server'ish
process that:</div>
<div>1. Creates a reference that is being passed along with the
pid, meaning, our start_link returns {ok, {Pid, ManageRef}} or
something like that. ManageRef is actually created within the
new process inside init/1 or such.</div>
<div>2. Introduce an operation named priority_call, which,
basically, sends something like {ManageRef, {Pid, Ref}, Msg}.</div>
<div>3. The process itself (on its own side) does a selective
receive like that:</div>
<div><br>
</div>
<div>receive</div>
<div> {ManageRef, From, Msg} -> handle_call(From, Msg,
State)</div>
<div>after 0 -></div>
<div> receive</div>
<div> Msg -> gen_server_like_dispatch_msg(Msg)</div>
<div> end</div>
<div>end</div>
<div><br>
</div>
<div>This could potentially help with sending managing messages
to the processes that may have overloaded inbox with thousands
of messages. Say, we see that the process gets overloaded and
we send an operational message of some kind ("discard the
entire inbox", for example).</div>
<div><br>
</div>
<div>Thoughts?</div>
</div>
</blockquote>
You could get this interaction by creating an internal service with
CloudI (<a class="moz-txt-link-freetext" href="http://cloudi.org">http://cloudi.org</a>). That means you just use the
cloudi_service behaviour for the service request receiver. You can
use the cloudi module to send from normal Erlang pids, or use the
cloudi_service behaviour to send from a second internal service.
Every CloudI service requests provides a unique v1 UUID to identify
the service request, a priority (defaulting to 0, but between -128
(high) and 127 (low), inclusive), and the source Erlang pid, in
addition to the two payloads RequestInfo and Request (where
RequestInfo is generally key/value message meta-data and Request is
the main data, both are any type when used with internal services).
The priority of the service request impacts the queuing of the
received service request, to determine the order service requests
get processed by a service. There is a queue_limit service
configuration option which can be provided for any CloudI service to
limit the number of pending service requests (i.e. unhandled) that
may be stored (<a class="moz-txt-link-freetext" href="http://cloudi.org/api.html#2_services_add">http://cloudi.org/api.html#2_services_add</a>). So, the
same use-case you have described with added features that includes
details for high-availability and partition tolerance.<br>
<blockquote
cite="mid:CANH2pzsHTGtvG-bQB7T4yfyb=rzCzymhrNuwjQfh=A-cyHXKeQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>-- <br>
Best regards,<br>
Dmitry Demeshchuk
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
</body>
</html>