Nut upsdev - Nov 2009 - drivers- dynamically adding filedescriptors to poll

Recent work on the netxml-ups driver made me realize that it would be  
very useful to be able to dynamically add/remove file descriptors we  
want to monitor for activity (instead of just a single extrafd). We'll  
probably also need this, in order to support asynchronous I/O in  
libusb-1.0. The latter would be a huge improvement over the existing  
libusb-0.1 (compatibility) interface we're using right now.

It is my intention to add something like the following:

typedef struct {
	struct pollfd *fds;
	nfds_t nfds;
	event_handler_t *handler;
} event_t;

typedef struct {
	struct pollfd fds;
	void (*callback)(void *data);
	void *data;
} event_handler_t;

int dstate_event_poll(event_t *events, int timeout);
int dstate_event_add(event_handler_t *handler);
int dstate_event_del(event_handler_t *handler);

When there is activity on a file descriptor, the handler for that file  
descriptor would be called with the data provided when the handler was  
added. This data could be a socket thats used for communication or the  
query to which this event is related.

The above is loosely based on the existing poll() in the upsd server,  
with the addition of being able to dynamically add/remove file  
descriptors and handlers. It is my intention also to make this part of  
common.[ch], so that we can use the same code in both drivers and  
server.

Any thoughts? Comments?

Best regards, Arjen

PS  I'll create a new branch for this, to also be able to play around  
with some libusb-1.0 code.
-- 
Please keep list traffic on the list

On Nov 14, 2009, at 6:48 AM, Arjen de Korte wrote:
> Recent work on the netxml-ups driver made me realize that it would  
> be very useful to be able to dynamically add/remove file descriptors  
> we want to monitor for activity (instead of just a single extrafd).  
> We'll probably also need this, in order to support asynchronous I/O  
> in libusb-1.0. The latter would be a huge improvement over the  
> existing libusb-0.1 (compatibility) interface we're using right now.
No objections here.

Since the libusb-1.0 implementation was fairly Linux-centric to start  
with, I presume we will have a long time before all platforms support  
it as well as libusb-0.1 -- but if you need the extra file descriptors  
for other drivers, I don't see a reason not to add that support.