in reply to Embedding a web-server in a long-running process?

If HTTP::Daemon worked this would be easy with a thread.

I take it back. My browser was being overzealous in it's caching.

Run this and the type http://localhost/status.htm in your browser. Refresh to see the status change.

Code updated: Corrected a couple of stupidities on my behalf and added an expires header to avoid the browser caching problem.

#! perl -sw use strict; use threads; use threads::shared; ## The main code stores the status information here ## Die is a flag used to ensure the thread shuts down properly. ## It could be made a separate variable if it is inconvenient. my %status : shared = map{ $_ => 0 } qw[ This That TheOther Die ]; sub statusThread { require HTTP::Daemon; require HTTP::Response; my $d = HTTP::Daemon->new( LocalAddr => 'localhost', LocalPort => +80 ) or die $!; my $resp = new HTTP::Response; while( my $c = $d->accept ) { warn "Accepted\n"; while( my $r = $c->get_request ) { warn "Requested\n"; unless( $r->method eq 'GET' and $r->url->path eq "/status.htm" ) { $c->send_error( 403 ); $c->force_last_request; warn "Denied\n"; next; } my $statusPage = '<HTML><HEAD><TITLE>Status</TITLE></HEAD> +<BODY>' . join( "\n", map { "<p>$_ : $status{ $_ }</p>" } grep{ !/Die/ } keys %status ) . '</BODY></HTML>'; $resp->code( 200 ); $resp->headers( Expires => scalar localtime ); $resp->content( $statusPage ); $c->send_response( $resp ); $c->force_last_request; warn "Responded\n"; } $c->close; warn "Closed\n"; undef($c); return if $status{ Die }; } } ## Create the web server in a thread my $daemon = threads->create( \&statusThread ); ## The rest of your program goes here my $life = 10000; while( --$life ) { $status{ (qw[ This That TheOther ])[ rand 3 ] }++; select undef, undef, undef, rand; } $status{ Die }++; $daemon->join

Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.

Replies are listed 'Best First'.
Re^2: Embedding a web-server in a long-running process?
by hsinclai (Deacon) on Mar 01, 2005 at 04:29 UTC
Re^2: Embedding a web-server in a long-running process?
by howie (Sexton) on Mar 01, 2005 at 10:16 UTC
    That's exactly the sort of thing I had in mind! However: it just quits without any error at all on OS X (which does have a threaded perl), it won't work on FreeBSD without rebuilding the whole of perl and it's modules (no threads), and on ActivePerl on XP it seems to have a binmode-related issue where the HTTP headers are double-spaced, so they're visible in the browser... I'd really like to just bolt this on the side of something and be done, but it looks like POE might be the right way to go, albeit with a steeper learning curve. Next thing is whether getting POE and appropriate components installed is less pain than getting a threaded perl. :-)

      This was only intended as an example, not a fully tested solution. What I know about writing HTTP servers is entirely captured in that post.

      It took all of 1/2 an hour to get it to the stage it is at now. It would have taken 10 minutes had my browser not been caching unexpired pages for at least 5 hours--which appears to be fixed by the addition of an "Expires" header.

      The XP issue is down to the -slw on the shebang line--now removed. The beneficial side-effect is that is removes the need for send_crlf, which I didn't think I should need, but it was late (or rather early).

      Ie. my fault. Updated. I'd appreciate someone with a threaded perl on OSX and Linux giving the modified version a spin in a few minutes.

      It obviously won't run without threads installed.

      POE may be easier to install. Maybe, if you have a lot of other packages already installed. I can sympathise with the Perl Upgrade problem.

      And if your application lends itself to be broken up into a state machine, then your laughing.

      The nice thing about the webserver in a thread, is that it would require no change to your existing application except a couple of : shared attributes.

      And maybe a few locks , but you can get away without those unless it is really important that all the values in displayed on your status page are exactly synchronised.

      Thanks for the feedback and good luck with your code.


      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.