Hi Fred.<div><br></div><div>Glad to hear that my posts amused You.</div><div><br></div><div>I use process_info because it is convenient: easy to manage data and easy to test.</div><div><br></div><div>Any ets table is an external dependency. Also it is too hard to keep process length in ets table eithout process info call.</div>
<div><br></div><div>Otp's current_function doesn't help beccause it shows something like gen:waitreply but i want to know what exactly process is doing.</div><div><br></div><div>High-level put(status, smth) helps.</div>
<div><br></div><div>The same is with initial function, it doesn't help to distinguish different streams<span></span><br><br>On Monday, January 14, 2013, Fred Hebert  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Max,<br>
<br>
Very interesting read. Really liked the following quote: "Deadlocked<br>
system maintain good load (about zero) but it provides bad service<br>
(about zero)".<br>
<br>
One thing you seem to rely a lot on is the use of process_info/2. I<br>
noticed you used it to get the message queue length, and also to read<br>
the process dictionary by foreign processes.<br>
<br>
Does accessing foreign data with process info have any noticeable cost?<br>
How does it compare to using ETS tables? Do you use the process<br>
dictionary due to better performances, or because it reduces the pain of<br>
maintaining multiple tables?<br>
<br>
I was wondering about using the message queue length as some arbitrary<br>
measure of load to implement ideas described in<br>
<a href="http://www.eecs.harvard.edu/~michaelm/postscripts/handbook2001.pdf" target="_blank">www.eecs.harvard.edu/~michaelm/postscripts/handbook2001.pdf</a><br>
<br>
Basically statistically optimal choices in [sequential] load-balancing<br>
can be made by picking 2 random entries, checking the load, and picking<br>
the most available one. Using message queue lengths for this would have<br>
been useful, but I was afraid doing it on average twice per request<br>
could have a prohibitive cost in a production system. I never tested it,<br>
but your post reminded me of that.<br>
<br>
Regarding the use of process dictionary to store states to debug<br>
(put(status, write_frame_on_disk), etc.), would you still use that system<br>
given newer OTP versions tell you what function they're currently<br>
running? I'm assuming the process dictionary is a bit more fool proof to<br>
refactoring when you come to rely on it.<br>
<br>
<br>
On 01/14, Max Lapshin wrote:<br>
> Meetup of erlang programmers was on 12 January in Moscow.<br>
><br>
> I was speaking about some useful tips for protecting erlang system from<br>
> overload and crash.<br>
><br>
> Here they are in posts:<br>
><br>
> <a href="http://blog.erlyvideo.org/2013/01/01/overload-protection-1/" target="_blank">http://blog.erlyvideo.org/2013/01/01/overload-protection-1/</a>  introducing<br>
> feedback inside system parts<br>
> <a href="http://blog.erlyvideo.org/2013/01/02/overload-protection-2/" target="_blank">http://blog.erlyvideo.org/2013/01/02/overload-protection-2/</a>  early<br>
> rejecting requests<br>
> <a href="http://blog.erlyvideo.org/2013/01/03/deadlocks-1/" target="_blank">http://blog.erlyvideo.org/2013/01/03/deadlocks-1/</a>  tips to workaround<br>
> deadlocks<br>
> <a href="http://blog.erlyvideo.org/2013/01/04/unobtrusive-read/" target="_blank">http://blog.erlyvideo.org/2013/01/04/unobtrusive-read/</a>  some notes about<br>
> non-messaging reads<br>
> <a href="http://blog.erlyvideo.org/2013/01/05/maintain-long-requests/" target="_blank">http://blog.erlyvideo.org/2013/01/05/maintain-long-requests/</a>  controlling<br>
> long user tasks<br>
><br>
> It would be good if this will be helpful to someone. Any feedback on these<br>
> ideas is welcome.<br>
<br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'erlang-questions@erlang.org')">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</blockquote></div>