[erlang-questions] On selective receive (Re: eep: multiple patterns)

[Chandru]

2008/6/3 Vlad Dumitrescu <vladdu55@REDACTED>:

> HI,
>
> 2008/6/3 Chandru <chandrashekhar.mullaparthi@REDACTED>:
>
>> 2008/6/3 Sean Hinde <sean.hinde@REDACTED>:
>>
>>> 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
>> happened.
>>
>>
> 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.

cheers
Chandru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080603/3db6e8b5/attachment.htm>