Take a look at <a href="http://www.erlang.org/doc/man/erl_driver.html">http://www.erlang.org/doc/man/erl_driver.html</a> and ERL_DRV_FLAG_USE_PORT_LOCKING. My guess is that you've got driver locking right now and it's failing when you try to acquire the lock again for the second port.<div>
<br></div><div>Cheers,</div><div>Joel<br><br><div class="gmail_quote">On Fri, Jul 29, 2011 at 5:41 AM, Bob Cowdery <span dir="ltr"><<a href="mailto:bob@bobcowdery.plus.com">bob@bobcowdery.plus.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi<br>
<br>
I have a linked-in driver which pretty much follows the example in the<br>
Programming Erlang book. This works very well and I've been using it for<br>
a while. I now need two separate instances of this so I went the easy<br>
route and created another gen-server for the second instance. Both these<br>
gen-servers spawn a reader process and make the reader the port owner.<br>
<br>
When I start up the program which is a full OTP implementation the<br>
supervisor kicks in and closes it all down. No error messages. I have<br>
discovered that when the second process spawns its reader the close down<br>
occurs with the reader of the first process exiting. If I don't spawn<br>
the second reader then it stays up and I can send commands from both<br>
processes but obviously can't read responses for the second process. I'm<br>
obviously doing something that is incorrect here but I can't figure what.<br>
<br>
Regards<br>
Bob<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto: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>
</blockquote></div><br></div>