Questions about Erlang port drivers

[Rich Neswold]

Hello,

I've written an Erlang port driver and ran across some puzzling behavior.

The hardware is connected to a CM11A module (RS-232C to X-10
interface.) My driver interface is implemented as a state machine,
since the protocol to the CM11A has a lot of handshaking. To avoid
getting locked up if the handshaking fails, I set timeouts in the
driver using driver_set_timer(). Specifically, if a state needs to
timeout, it calls driver_set_timer() otherwise it calls
driver_cancel_timer().

This works fine for simple X-10 commands (like turning lights on or
off), but when a slower command is sent (dimming, for instance) the
state machine times out waiting for a response. Adding copious debug
statements revealed that the hardware was responding fine, but the
Erlang runtime was calling my timeout callback! Increasing the timeout
had no effect.

I was able to "fix" the problem by always calling
driver_cancel_timer() and then conditionally calling
driver_set_timer() when changing states. I inferred from the
documentation that driiver_set_timer() would cancel any pending timers
before setting the new timer, but the actual behavior doesn't follow
this logic.

I put "fix" in quotes because maybe the problem is with concurrency. I
use a thread pool (the +A command line option) when I start my
application. Does the Erlang runtime guarantee only one thread is in a
given instance of my driver at a time, or do I need to worry about
concurrency issues?

Did I misunderstand the timer function? Do we always need to call
cancel_timer before calling set_timer? Any information is appreciated.

--
Rich

AIM : rnezzy
ICQ : 174908475