I've been trying to get the tools/webserver working, because I'm thinking
of modifying it to act as a documentation server (by formatting stuff in
our special undecided way).
I have noticed broken pipes and many other bugs and I have seen this
ages ago on linux too. So whilst RF's demux code may be a bit shaky
and the faio bindings on top of it shakier .. one would expect some
platform dependency etc .. welllll ..look at my webserver code:
// up the queue len for stress testing
var p = webby_port;
var listener: socket_t;
mk_listener(&listener, &p, 10);
forever {
var s: socket_t;
accept(listener, &s); // blocking
dbg$ "got connection "+str s + "\n"; // error check here
// hmm - spawning an fthread is blocking the web server. don't know why
print "spawning fthread to handle connection\n";
spawn_fthread {
dbg$ "Spawned fthread running\n";
// should spawn fthread here to allow for more io overlap
var line: string;
get_line(s, &line); // should be the GET line.
print "got line: "; print line; endl;
Can you see the problem?
Hint: this thing seems to work once, for the first page. Then it craps out.
It especially craps out in weird ways on pages which fetch images etc,
i.e. trigger multiple requests during the load from the client.
and note:
proc forever (bdy:unit->void)
{
rpeat:>
bdy();
goto rpeat;
dummy:> // fool reachability checker
}
The problem is clear when you know it. When a new fthread is spawned ALL
the fthread are using the socket s.
Why? It's because the body of forever is inlined, so all the fthreads are using
the same variable s for the socket. So half way through processing a file
another request is sent by the browever for an image and a new
socket is allocated .. and the original fthread starts using that too.
There are several work arounds. One is to stop "bdy()" being inlined,
by making the parameter a var, which forces a closure.
The second is to use recursion instead of forever, however that
might do the same thing (since tail rec optimisation is a goto,
though there is an eager assignment of the argument, which
should fix it )
The third (proper) way is to use a channel to pass the socket
to the fthread.
There's a fourth way: copy the socket in the fthread. Now, at present
this won't work because when you spawn an fthread there are
TWO threads to run, and felix choses one at random. In the
current implementation the main thread keeps running and the
fthread is suspended (because this is slightly faster).
If this was changed so the fthread was specified to run instead,
the fthread could safely copy things up from its context, since it
would retain control until yielding it. However this is a hack,
since fthreads can yield control at unexpected moments.
--
john skaller
skal...@users.sourceforge.net
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
