gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Camm Maguire
Subject: Re: [Axiom-developer] Re: [Gcl-devel] Simple web server code for GCLfor Windows
Date: 28 Apr 2005 22:36:34 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

"Mike Thomas" <address@hidden> writes:

> Hi Camm/Bill
> 
> Camm wrote:
> 
> | Greetings!  Here's a quick way to get started:
> |
> | ==================================================================
> | ===========
> | address@hidden:/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                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]