[erlang-questions] Reinserting a message into a gen_server's mailbox

[Juan Jose Comellas]

I'm aware that I can do a gen_server:reply/2 from any process, but I was
planning on issuing the gen_server:reply/2 calls from the gen_server process
because that's where I'll be queueing up the requests.

You're right, the second option is a form of polling, but it makes the code
simpler, and I only have to load the external data once from the gen_server
process, so it wouldn't have mattered that much.

Anyway, thanks for your comments, I'll probably end up doing it in the
correct way.

I'm still curious, though, does the format of these internal messages ever
change? What happens if I use two different Erlang/OTP versions in my nodes?
Does the newer VM/library still accept the old version of the messages?


On Thu, Jul 29, 2010 at 12:55 PM, Gleb Peregud <gleber.p@REDACTED> wrote:

> On Thu, Jul 29, 2010 at 17:15, Juan Jose Comellas <juanjo@REDACTED>
> wrote:
> > 1) The "correct" one: keep the list of requests that come in while the
> data
> > is not ready and once I have the data in the helper process, notify the
> > gen_server process and do a gen_server:reply/2 with the response for each
> of
> > the pending requests.
> AFAIK there is no need to do gen_server:reply/2 from the gen_server
> itself - one can send reply from absolutely any process. So just
> proc_lib:spawn_link/1 a worker process for long tasks and do
> gen_server:reply/2 in it when it finishes the task. In fact there is
> even no need to store a list of requests in gen_server.
>
> > 2) The easy (non-kosher) one: while the data is not ready reinsert all
> the
> > requests (that depend on the data) that come into the gen_server process
> > back into its own mailbox (maybe with a little delay) and hope that when
> > they are processed again the data will be ready.
> This is a form of polling. Why do you want one? "Correct" solution is
> much-much more elegant and efficient. I can't see a situation when
> this solution would be better...
>
> Best,
> Gleb Peregud
>