[erlang-questions] On selective receive (Re: eep: multiple patterns)
Tue Jun 3 14:03:11 CEST 2008
2008/6/3 Vlad Dumitrescu <>:
> 2008/6/3 Chandru <>:
>> 2008/6/3 Sean Hinde <>:
>>> On 2 Jun 2008, at 14:31, Chandru wrote:
>>> I respectfully disagree. It is nigh on impossible to predict where there
>>> might be some error that leads to a large queue, and this would lead to
>>> "defensive programming" where every process has a short max length. This
>>> would result in random crashes and loss of data for those uncommon
>>> situations in an generally well designed system where there might be a
>>> legitimate short term peak in queue lengths.
>>> We already have a mechanism to restart if a queue grows too large
>>> (actually 2 - process_info monitoring, and out of memory !)
>> I agree it is nearly impossible to predict this - but what options does a
>> programmer have without this bounded queue facility.
>> 1. Introduce message queue monitoring for every process which is
>> potentially long lived, which imho is extra boiler plate code which reduces
>> readability of core functionality. Also there will be different ways of
>> doing it depending on how your process is structured (gen_fsm, gen_server,
>> gen_event, pure erlang...). If all that one does upon detecting this
>> condition is clear the message queue by discarding messages, or terminate
>> the process, wouldn't it be good to have this built-in?
>> 2. have another process which monitors the entire system - which is not
>> very scalable when you have hundreds of thousands of processes.
>> 3. Wait for the system to crash in live and then figure out what
> An alternative to the crash-when-queue-is-full solution could be that a
> user-defined function gets called first. This function should use
> application-specific knowledge to clean up the queue with the least amount
> of disturbance for the application. The process should crash only if this
> cleanup is still not enough or if the function sets a new higher threshold
> for the queue length. The function could also turn on debug mode so that the
> reason for the many messages is found as it happens.
I agree. This would be useful too.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions