> > events.c(67) : error C2061: syntax error : identifier 'sig_int' > > sig_atomic_t needs config support. > Or as you said below, move all signal stuff to platform code - then I guess we have config support for it without anything new/extra/special.
> > events.c(564) : error C2065: 'fd_set' : undeclared identifier > > win32 has select() AFAIK - might need just another header file. > It has a select() function, but looking at the docs no mention is made of pipes - just sockets. > > PIPES > > > It looks like things like fd_set don't deal with pipes here either, just > > sockets; see:- > > Argh, what an OS. Anyway the communication with the io_thread could be > done with sockets. Does the Win32-API provide socketpair()? > Unless I'm missing something, no. It's only mentioned in the porting UNIX apps to Windows docs - thus it is most probably provided by the Interix UNIX emulation layer (part of Windows Services For UNIX). It's not mentioned anywhere other than that in the MSDN (just the one search result...) Is there any reason not to have our own pipe "abstraction" (e.g. stuff in platform.c/.h)? Win32 does have pipes, after all - they just need setting up a little differently. Or if there is more concern over platform specific issues, even a complete abstraction for communication with the I/O thread, so we can do it as sockets or pipes behind the scenes (or whatever else) on a platform-by-platform basis. Perhaps that's going to far, I'm not familiar enough with the range of platforms out there to know. > > SIGNALS > > Win32 doesn't have usable signals. All code dealing with signals will > move to platform files anyway. OTOH we need a Win32 event loop to be > able to catch program termination. > OK, sounds like a plan. Thanks, Jonathan
