<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><font face="courier new, monospace">...<br>handle_call({run, Args}, _From, {Limit, Spv, Refs, Queue}) when N > 0 -><br> {ok, Pid} = supervisor:start_child(Spv, Args),<br> Ref = erlang:monitor(process, Pid),<br> NewRefs = gb_sets:add(Ref, Refs),<br> NewState = {Limit-1, Spv, NewRefs, Queue},<br> {reply, {ok, Pid}, NewState};</font><br></div><div><br></div><div>We also can use the above alternative code right?<br></div></div></div></blockquote><div><br></div><div>Yes, you can use whatever Erlang term you prefer - record, tuple, map, a list of maps containing records of tuples...</div><div><br></div><div>What you choose is a matter of taste and depends on your requirements. A record for instance has the advantage over a tuple, that you access elements by name and the order of elements therefore becomes irrelevant. This could give advantages if you one day decide to add another field to your state. With the tuple approach this would likely break every access to the tuple everywhere in the code, but with a record where you access and match by names most of your code might still work...plus you never need to remember what meaning the third or fourth element in your tuple has l, because it has a descriptive name.</div><div><br></div><div>Stefan </div></body></html>