driver_output_term() and unsigned long (32 bit) values

[Shawn Pearce]

Per Bergqvist <per@REDACTED> 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.

--
Shawn.

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.''