driver_output_term() and unsigned long (32 bit) values
Fri Jul 26 18:52:08 CEST 2002
I rest my case, it would make sense to have a driver_mkref.
On the topic of extending the driver interface:
Today there is only one timer available for a driver.
Driver authors that have need for more timers have to implement
timer wheels on their own or multiplex the timer in other ways.
This is not always an ideal situation (like in inet_drv where
the driver tries to keep track of both read and write timeouts).
I would like to expose the timer wheel of the vm to the drivers
to avoid re-inventing the wheel (:-).
My proposal is to :
Add a callback function ext_timeout(ErlDrvData, int) to the driver
driver_set_ext_timer(ErlDrvData, int, ulong)
driver_cancel_ext_timer(ErlDrvData, int, ulong)
driver_read_ext_timer(ErlDrvData, int, ulong)
> Per Bergqvist <> scrawled:
> > > For what it's worth, it doesn't appear possible to have the
> > > create a reference and send that back to Erlang, either.
> > >
> > IMHO, I think it is a bad idea to allow a driver to create a
> > since references should be unique and it will be hard to guarantee
> > uniqueness if there are several allocators ...
> Why not a function:
> ErlDrvTerm driver_mkref()
> which will always use the internal reference allocator? Or is it
> not possible to use the existing allocator underlying erlang:mkref/0
> while a driver is executing?
> It would be very convient for drivers to be able to use references,
> esp. as the references could be stored in a small hash table linking
> to driver specific objects, for example a widget in a GUI library.
> Of course, driver authors could still try to send illegal reference
> values by attempting to create their own references without the
> driver_mkref() function. But today driver authors could also try to
> make an ErlDrvBinary on their own without driver_alloc_binary(), and
> the results would be just as bad.
> I had really considered making a bunch of ErlDrvBinary objects in a
> mmap region at one point, until I noticed in the Erts source that
> ErlDrvBinary is not the entire binary structure - there is data
> before it by the emulator. I would have had pretty ugly results had
> I tried to use my own binary.
> Therefore I'm arguing that its acceptable if there are ugly results
> because a driver author used a value for a reference which did not
> come from driver_mkref().
> Why do I like Perl? Because ``in accordance with Unix tradition
> gives you enough rope to hang yourself with.''
> Why do I dislike Java? Because ``the class ROPE that should contain
> method HANG to do the hanging doesn't exist because there is too
> 'security' built into the base language.''
Synapse Systems AB
Phone: +46 709 686 685
More information about the erlang-questions