More Driver Questions :-)

[Bruce Fitzsimons]

Thanks for your help, the penny has dropped.

While I am blocking SIGPOLL inside my signal handler, and therefore avoiding
reentrancy problems there, I did not know that malloc/free are usually not
re-entrant.

So while my code is reentrant safe, the process of sending the buffer to
Erlang via driver_output *must* allocate memory at some point (and/or use
other unsafe code), and if perchance Erlang was already allocating memory
when the signal occurred then all hell breaks loose.

This explains so many things...and makes me appreciate Erlang more :-)

Thanks for the pipe idea Per, I will see if I can use that. I think a major
redesign of the driver is overdue.

I was also thinking about Raimos idea with respect to using pre-allocated
binaries (and putting sig_hold/sig_release around the counter update). I
think the major problem is that I am relying on internal Erlang code
(driver_output_binary) not using non-reentrant functions, its probable but
not under my control. If the Erlang code was updating the ref_count and was
interrupted by the signal handler updating the ref_count it could be bad.

The nasty thing about these problems is they only occur after you start
using the code heavily :-(

Once again; thanks, this was driving me crazy.

Cheers,
Bruce