Okay, thanks for that info.
Are you assuming that the user calls pump, or does pygame have some internal thread that consistently calls pump?
I haven't dug around very much inside the code, so I don't know how it looks in there, but it seems like the pygame.event.pump code is already doing periodic input work,
or does pygame.event.get call pump as well?
The other pygame event methods (get, peek, poll...) call the SDL pump themselves, there is no separate thread. On the SDL side of things, SDL_Pump just pulls events off the Windows event queue (or equivalent) and places the matching SDL events on the SDL event queue in their place.
The only reason I was doing overlapped I/O was because it enables you to write to the device even if a read is blocking at the time [or so Microsoft tells me].
There's no way to hook into the SDL pump function, so you'd need to be asking the user to pump it from their own event loop.
From your wiimote pump function, it's up to you how you decide to post events. On Windows your overlapped IO idea sounds fine, if complicated; Mac and Linux don't have the same overlapped I/O interface though (a simpler read with timeout).
Good point, I'll take that into consideration.
I would personally prefer if your wiimote library wasn't tied in directly with Pygame (by posting its events into the Pygame/SDL event queue), but instead provided an equivalent poll(timeout=None) function. This would allow it to be used with other windowing libraries, and you could still provide a Pygame wrapper around the poll function for ease of use within Pygame.
Cheers and good luck Alex.