[snip] > I posted a sample earlier, but the common ground is: register a > function, file descriptor, and pointer; the function is called with > the file descriptor and pointer as arguments whenever the file can be > read or written, or is closed. Both the GUI and the HID may need > small wrapper functions to convert from the hid's api to whatever api > they're using (they already do this for timers).
Sorry, of course: """ hidval watch_file (int fd, void *user_data, void (*callback)(int, void *)); void unwatch_file (hidval which); """ > > Since the watch types, G_IO_IN, G_IO_OUT, etc.. might not be guaranteed > > to line up with the enum constants in other mainloops (but probably > > will, as presumably they are just passed to select), do we need to write > > our own enum list, and map it onto the correct values in each hid? > > I'd say ignore the condition. Just do read/write/close, that's all > that really happens on normal sockets. The hid can call a polling > select() to figure out what states are ready on the file. OK, I expect this is workable. If any of the conditions are true, then we want to do something, so it looks fine. Means you can't register different callbacks for different actions, read/write etc.., but I'm not entirely sure if select allows that anyway. Peter _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
