<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">If I understand you correctly, you would essentially busy-loop over the ETS table until the object is gone? This would not be constant time.</div><div class=""><br class=""></div><div class="">Selective receive can be done largely in constant time if you take care, e.g.</div><div class=""><br class=""></div><div class="">call(Pid, Req) -></div><div class=""> Ref = erlang:monitor(process, Pid),</div><div class=""> Pid ! {‘$call’, {self(), Ref}, Req},</div><div class=""> receive</div><div class=""> {Ref, Reply} -> Reply;</div><div class=""> {‘DOWN’, Ref, _, _, Reason} -> error(Reason)</div><div class=""> end.</div><div class=""><br class=""></div><div class="">The above will be detected by the compiler as an optimizable construct, since all patterns in the receive clause contain the newly created unique reference Ref. Therefore, the compiler can ‘mark’ the end of the message queue before creating Ref, then jump directly to the mark for the receive. No messages before the mark can contain Ref, since it didn’t exist then.</div><div class=""><br class=""></div><div class="">This optimization is built into gen_server:call(), but you can exploit it yourself by ensuring that the Ref creation (either monitor() or make_ref()) is done in the same scope (same function) as the receive, and the patterns in the receive clause all contain Ref.</div><div class=""><br class=""></div><div class="">The cost of the receive would be proportional to the number of messages arriving to the receiving process while it’s waiting, since it has to pattern-match on each.</div><div class=""><br class=""></div><div class="">BR,</div><div class="">Ulf</div><div class=""> </div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 31 Jul 2015, at 17:13, Avinash Dhumane <<a href="mailto:nistrigunya@gmail.com" class="">nistrigunya@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class="">I have a need to lookup a tuple based on a 32-bit integer key and remove it from a set after it is found. The set is shared by 2 processes - one inserts the tuple and the other performs a lookup followed by a delete.<br class=""><br class="">So, I am considering ETS versus selective receive. Consideration for selective receive because I need the lookup call to block until the tuple becomes available in the set.<br class=""><br class=""></div>I suppose selective receive will not be able to lookup in constant time whereas set-ETS will! But, I favour the selective receive because it makes the code so simple and intuitive. <br class=""><br class="">So, my question is this - till what point, in terms of number of tuples in the set, the selective receive will be effective. The insertion in the set is capped at 400 tuples per second, but the lookup (followed by a delete) will be considerably slower (by 20 to 70%) than the rate of inserts.<br class=""><br class=""></div>Please advise on considerations that apply in this situation in order to employ a suitable scheme.<br class=""><br class=""></div>Thanks<br class=""></div>Avinash<br class=""></div>
_______________________________________________<br class="">erlang-questions mailing list<br class=""><a href="mailto:erlang-questions@erlang.org" class="">erlang-questions@erlang.org</a><br class=""><a href="http://erlang.org/mailman/listinfo/erlang-questions" class="">http://erlang.org/mailman/listinfo/erlang-questions</a><br class=""></div></blockquote></div><br class=""><div apple-content-edited="true" class="">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class=""><div class="">Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.</div><div class=""><a href="http://feuerlabs.com" class="">http://feuerlabs.com</a></div></div><div class=""><br class=""></div></span><br class="Apple-interchange-newline">
</div>
<br class=""></body></html>