[erlang-questions] Terminate process if it is slow at receiving messages

akonsu akonsu@REDACTED
Fri Sep 20 17:08:20 CEST 2013


Hello,

I have posted this question to stackoverflow (
http://stackoverflow.com/questions/18895614/terminate-process-if-it-is-slow-at-receiving-messages)
and received one helpful response, but I am still not clear about the right
way to do it.

 I also have seen this thread:
http://erlang.org/pipermail/erlang-questions/2011-June/059335.html, which
is somewhat similar but it still did not hep me.

I would appreciate more help. Here is the question:



I have a data source process that sends messages to worker processes. To
keep memory consumption under control, I need to terminate the workers that
are slow retrieving their messages from their mailboxes.

I am new to Erlang, I would appreciate any pointers. If this is difficult
to accomplish with Erlang messages, maybe I can use sockets? If so, are
there examples?

EDIT:

I have a registered process that reads from the web and generates a lot of
data. It sends these data to all the "subscribed" processes using Erlang
messages. For each particular piece of data, it sends the same message to
all subscribers.

I also have a web server that streams the data that the registered process
reads. So, when a http client connects, the web server creates a process
and this process subscribes to the registered process and starts receiving
its messages.

The registered process uses monitors to monitor subscribers. The
subscribers are controlled by the web server, and when a connection is
closed, the process that were serving this connection, dies.

There is no acknowledgement, that is, subscribers do not respond when a
message is sent to them. Although I can program them this way, but I think
it is too much traffic.

Basically I want to close the connection if a http client is too slow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130920/78a127fb/attachment.htm>


More information about the erlang-questions mailing list