On Fri, Jan 01, 2016 at 08:09:10PM +0100, Geoff McLane wrote: > Hi Karl, Adam, > > Well I think pipes and sockets seem certainly the most > practical cross-platform IPC mechanisms... I agree with that and if we were doing a traditional client server I'd go down that route for sure. > Pipes seems to have less difference in that only perhaps > a few #ifdef WIN32 are required, if any, in a cross-compile...
But multiple processes can't monitor a pipe as far as I know. > Sockets definitely does require a number of #ifdef WIN32, > but not really excessive... many can be handled as MACROS... > and the cross-porting has been done MANY times... in lots > and lots of libraries, apps, utilities, so is sort of very > mature... getting easy even... I wonder if what we actually should be doing is looking for a cross-platform IPC lib? > But reading up a little on MSDN, and remembering, the > following IPC mechanisms are available in Windows, but > for sure some are **WINDOWS ONLY**! > > 1. Clipboard/DDE - can agree a format then do copy/paste Yuck, is that really done within apps? > 2. COM - OLE manage compound document interface ... ouch! That's gonna be ifdef hell. > 3. Data Copy - Using Windows messaging - WM_COPYDATA Don't know about this, sounds potentially interesting though. > 4. RPC - have only ever used it over sockets... Yeah, usually a socket technology as far as I know. > 5. File Mapping or shared memory mapping - just put data Unix has this via mmap, never used it for IPC but I've used it for other things. There'll be sync issues this way, lots of 'em. I know apps do IPC this way, and successfully though. > 6. Pipes and Sockets - are cross-platform... Yep. > Not sure which of these would fit "domain sockets", but maybe > I missed something else available... having coded and used > most of them, in various apps, at various time, I am not sure > which I would choose as the most 'generic' to Windows... How about named pipes? I just looked them up on msdn and it looks like we could may be do that. I'm not sure if it's directly equivalent to unix domain sockets or may be the unix equivalent is more like a fifo, but either way that'd work. Actually fifos would work quite nicely. Edbrowse-curl, per user, monitors an input fifo, then creates output fifos for each connected edbrowse instance. That way we can have $tmpdir/edbrowse/$user/edbrowse-curl/input and then numbered output fifos. > I am sure unix has some form of shared memory mapping (5)... just > copy a data block using a simple memory pointer would probably be > the fastest... but requires that the partner be monitoring that > space, polling... and what about thread safety? and maybe needs > some/many #ifdef to account for the differences... Yeah as I said above, certainly possible but the synchronisation issues will be awkward, and there're probably differences as well as you point out. > But as Karl mentions he has already shown 6. Pipes and Sockets > both work... with no porting issues that I know of... Agreed. > Concerning sockets, over the years I have collected some tcp, > udp samples, and this is where I added and tested Karl's > socket.c - and pushed them all to my 'new' tcp-tests repo - > > https://github.com/geoffmcl/tcp-tests > > See src/ebsocket.c... compiles without even a warning both > in WIN32 and UNIX... still to do a WIN64 compile... and > maybe a MinGW compile... sockets are fun ;=)) and really > now quite an old technology that has not been replaced... Ok, not to forget cygwin... and the 32 and 64 bit versions of those, though I should imagine that we should be fine as long as we don't try running 64 bit libs on 32 bit Windows. ... fun as you say. Cheers, Adam. PS: has any of this altered with Windows 10?
signature.asc
Description: PGP signature
_______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
