driver_output_term() and unsigned long (32 bit) values

Shawn Pearce <>
Fri Jul 26 22:57:17 CEST 2002

Per Bergqvist <> scrawled:
> I would like to expose the timer wheel of the vm to the drivers       
> to avoid re-inventing the wheel (:-).                                 

This is a good idea.  ;-)

> My proposal is to :                                                   
> Add a callback function ext_timeout(ErlDrvData, int) to the driver    
> entry.                                                                
> Add functions:                                                        
> driver_alloc_ext_timers(ErlDrvData, int),                             
> driver_free_ext_timers(ErlDrvData),                                   
> driver_set_ext_timer(ErlDrvData, int, ulong)                          
> driver_cancel_ext_timer(ErlDrvData, int, ulong)                       
> driver_read_ext_timer(ErlDrvData, int, ulong)                         

This interface would work well I think.  I'm kicking around the idea of
having a ErlTimer type (like an ErlDrvBinary) that can be alloc'd and
managed through some functions, rather than working with a set of timers
at once.  I'm not sure of what the impact would be to driver API/code clarity
either way, nor what the impact would be to the internal timer code of the VM.

One thing I do like about Erlang drivers is they are so easy to write.  The
API is very short, to the point, and definately does not make it awkward to do
driver development.


Why do I like Perl?  Because ``in accordance with Unix tradition Perl
gives you enough rope to hang yourself with.''

Why do I dislike Java? Because ``the class ROPE that should contain the
method HANG to do the hanging doesn't exist because there is too much
'security' built into the base language.''

More information about the erlang-questions mailing list