Greetings! "Mike Thomas" <[EMAIL PROTECTED]> writes:
> Hi Camm/Bill > > Camm wrote: > > | Greetings! Here's a quick way to get started: > | > | ================================================================== > | =========== > | [EMAIL PROTECTED]:/fix/t1/camm/debian/gcl/gcl-2.6.6$ diff -u > | ../gcl-2.6.5/o/file.d o/file.d > | --- ../gcl-2.6.5/o/file.d 2004-05-07 21:48:58.000000000 +0000 > | +++ o/file.d 2005-04-28 16:21:33.000000000 +0000 > > ... > blah blah... > ... > > | > | >(bar 8080 #'foo) > | ================================================================== > | =========== > | > | Then point your browser to localhost:8080. You should be able to get > | directory listings and files. > > I modified the test program to print stuff out and using port 8085 to get > around IIS I was able to get a web page back with the following text: > > /TMP /win32app /WINDOWS > > from the following input into my browser: > > http://localhost:8085/dir > > So it looks like your patch works on Windows Camm to a first approximation - > you truly are a wunderkind Camm! > Great!, but hardly... > > | 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. threads need reentrancy, no? None of our code has been checked in this regard, and there are known issues with things like gc. Yet our mingw port can both run gcc and do run-process, both of which exist atop fork() on unix. Are these using some type of threading? Or rather is a completely unrelated process with an entirely distinct memory image started? 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? > > | Speaking of which, does MS have select? > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/win > sock/select_2.asp > > but you should be warned that Windows socket functions are often different > to the original Berkeley APIs and select is not able to handle the range of > fd types used in Unix. Thanks! My peanut sized brain parses this as 'it should work, but it might not' :-). > > | There are other hooks for > | allowing work in the image while connections are handled in the > | background, e.g. SIGIO, but don't know the portable nor most desirable > | way of doing this. > > Signals are a mistake for portability to Windows. > 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. Take care, > Cheers > > Mike Thomas. > > > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
