Hi Camm. | > | It is trivial to fork() in linux for each | > | connection, but don't know how this would be done on Windows. | > | > Threads. | | OK, now I'm confused.
Sorry. | threads need reentrancy, no? Yes. | None of our code | has been checked in this regard, and there are known issues with | things like gc. Yes. | Yet our mingw port can both run gcc and do | run-process, both of which exist atop fork() on unix. On Windows the concept of cloning an already running process down to the program counter ie fork() does not exist. | Are these using | some type of threading? Or rather is a completely unrelated process | with an entirely distinct memory image started? Yes, that is what CreateProcess() does: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/b ase/createprocess.asp | fork() on unix these | days uses copy on write pages, making it fairly lightweight. Am I | right in assuming that if we did server sockets with the idea of a | separate process handling each connection, that we would have to start | an entirely new gcl on windows to do such (i.e. inheriting no work | done previously in the session), at least at the moment? Would this | effectively double the virtual memory consumption? Yes. Threads are the usual process related method of avoiding such wastage. I suppose that the trade off is between running multiple threads in the same address space (ie a threat to one thread is a threat to the entire process) versus frigging around in the interprocess communication jungle and having hung/broken pipes etc. | Thanks! My peanut sized brain parses this as 'it should work, but it | might not' :-). I think that's a good way of looking at it. I've never used select() myself. That function, like all of the others in the Microsoft Visual C Runtime, including standards like "fopen()", is built on top of far more sophisticated functions in the real Windows system APIs - ie, the ones you get through <windows.h>. So select() is based on WaitForMultipleObjects() and fopen() on CreateFile() and there are really no such things as either file descriptors or FILE *. They are, rather, an illusion built on the true workhorse of the Windows OS, namely, HANDLE's. In short, the entire Microsoft Visual C++ runtime was designed as a sop for Unix C programmers and, in fact, a well designed Windows program does not bother with any of those artifacts whatsoever. | OK. This still leaves us with the three broad options for server | sockets: multitasking, file descriptor/standard input multiplexing, or | user server invocation. | The existing hooks in the original code stores the server function in | the socket stream itself. This makes natural the idea that once one | does (si::socket p :server #'foo), the connection handling, or the | accepting, or both should be registered and handled automatically. It | would be nice to get a feel for how people would like this to work. This is definitely out of my realm of expertise so I'll trust you to work that out. Cheers Mike Thomas. _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
