<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 18, 2013 at 4:02 PM, Tim Watson <span dir="ltr"><<a href="mailto:watson.timothy@gmail.com" target="_blank">watson.timothy@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 18 Jun 2013, at 14:35, Lukas Larsson wrote:<br>
><br>
</div><div>> The good thing about using the driver queue is that if there is data and a flush callback is implemented you can make sure that data is handled before closing the port. So that you don't loose things which you might need. If you do notice that you get a lot of contentions on the pdl you can of course roll your own more fine grained locking and just stick a byte of data in the driver queue in order to trigger flushes.<br>


><br>
<br>
</div>Oh, that's nifty, I like it. Is there any benefit to doing that versus creating a pipe and using driver_select to signal/check?<br></blockquote><div><br></div><div>Not sure. What will happen is the port will remain in the system (but all links will be triggered and you cannot interact with it from erlang) and you can continue doing ready_output/ready_input until you clear the driver queue. When the queue is cleared the normal stop behaviour happens.<br>
<br></div><div>IMO it sometimes makes for nicer code as you don't have to worry about the port being tugged away from under your feet when you have data in the queue which has to be delivered. <br></div><div> <br></div>
<div>Lukas<br></div></div></div></div>