[erlang-questions] Driver Threading & Message Sending
Rickard Green
rickard.s.green@REDACTED
Tue Sep 18 11:32:01 CEST 2007
Rickard Green wrote:
> You can only use driver_output() from "emulator threads".
Correction: The async thread pool are "emulator threads", but you cannot
call driver_output() from them. You can only call driver_output() from
the scheduler threads of the emulator.
BR,
Rickard Green, Erlang/OTP, Ericsson AB.
> When the
> runtime system with smp support is used, you can use driver_send_term()
> from any thread.
>
> See http://www.erlang.org/doc/man/erl_driver.html for more info.
>
> BR,
> Rickard Green, Erlang/OTP, Ericsson AB.
>
> Benjamin Tolputt wrote:
>> More questions though this time (while related to Stand Along Erlang, it
>> also applies to general Erlang driver stuff I am developing).
>>
>> The benefit of Erlang which are pushing me to evangelize it to the game
>> development crew is the high concurrency and CPU utilization on
>> multi-core machines (i.e. it's SMP capabilities). To this end, they
>> asked if it would be possible for them to run their physics & AI modules
>> in a separate started up in a Erlang driver. This seems quite possible,
>> but I wanted to know a couple of things about how threading & drivers
>> are allowed to operate.
>>
>> Let's say that a driver is created for the AI engine utilizing whatever
>> techniques they desire for this. Let's also assume that they are running
>> this in a permanent loop (the classic "while (true)" thing) with input
>> coming in from Erlang through the driver interface and sending messages
>> back out the same way.
>>
>> Is it safe for the driver code to call the "driver_output" function from
>> a thread other than one in which the emulator "calls into" the driver
>> (i.e. is it possible to call driver_output from a thread not started by
>> the emulator)? If not, what is the common method used to get output
>> generated by the driver independent of queries (i.e. a call to the
>> drv_output driver callback) from Erlang? Polling for output from the
>> driver seems a bit strange given the message-centric method of
>> everything else, but I haven't been this low-level with Erlang before...
>>
>> Regards,
>> B.J.Tolputt
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
More information about the erlang-questions
mailing list