RE: [Axiom-developer] Re: [Gcl-devel] Simple web server code for GCLfor Windows

[Mike Thomas]

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.