driver_output_term() and unsigned long (32 bit) values

[Per Bergqvist]

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    
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)                         
                                                                      
Comments ?                                                            
                                                                      
/Per                                                                  
                                                                      
> Per Bergqvist <per@REDACTED> scrawled:                              
> > > For what it's worth, it doesn't appear possible to have the     
driver                                                                
> > > 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      
reference                                                             
> > 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   
the                                                                   
> ErlDrvBinary is not the entire binary structure - there is data     
stored                                                                
> 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().                                           
>                                                                     
> --                                                                  
> 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.''                          
>                                                                     
=========================================================             
Per Bergqvist                                                         
Synapse Systems AB                                                    
Phone: +46 709 686 685                                                
Email: per@REDACTED