Re^2: Embedding a web-server in a long-running process?

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. :-)

Comment on Re^2: Embedding a web-server in a long-running process?

Replies are listed 'Best First'.
Re^3: Embedding a web-server in a long-running process? by BrowserUk (Patriarch) on Mar 01, 2005 at 11:14 UTC
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 `lock`s , 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.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Embedding a web-server in a long-running process?
by BrowserUk (Patriarch) on Mar 01, 2005 at 11:14 UTC

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.

[reply]
[d/l]
[select]