More Driver Questions :-)

[per@REDACTED]

"Bruce Fitzsimons" <Bruce@REDACTED> wrote:
>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.

Actually, it's basically guaranteed that driver_ouput[_binary] *will*
use non-reentrant functions I believe - the only question is whether it
will bite you (or rather *when*:-). Even leaving aside malloc/free and
reference counts, whatever you send will be put on the input queue of
some process - if that input queue was being manipulated (another
process sending to it, or the process itself extracting a message from
it) when the signal occured, the result has a very high probability of
being a Mess(tm). And there is more... - e.g. the process may be
scheduled to run as a result of receiving your message, if the run queue
was already being manipulated when the signal occured, etc... - well,
you can read the code yourself.:-)

--Per Hedeland
per@REDACTED