On 03/03/2010 03:22 PM, p...@0ne.us wrote:
Tip: The POE developers have spent years optimizing POE the best they
can. You can safely ignore the core POE modules from your profiling (
POE::Loop::Select, POE::Kernel, etc ) and focus on your own code when
profiling.
I both agree and disagree
Hmmm... I thought I had a ticket for the connect_errors failure, but I
don't see it now. Maybe I just talked about it on IRC.
I haven't played with this for a few weeks, but as I recall Windows is
simply refusing to timeout the connection. If connect_errors.t is
modified to use the
Andreas Altergott wrote:
Hi,
Andrew Feren wrote:
I removed the calls to exit() and the service started working as
expected. Calling exit() from the child resulting from perl's pseudo
fork is supposed to work (and often does). Unfortunately it has been my
experience that sometimes
done. I would also take to heart his comment in rt bug
31458 that reliance on Win32::Daemon would be adventurous.
More comments inline below...
Andreas Altergott wrote:
Hi,
Andrew Feren wrote:
Andreas Altergott wrote:
Did you try the suggested change?
Yes, I did. It did not work
While I have several unresolved issues with fork on Windows I think they
biggest problem with your script is that the fork logic backwards.
Something like the following will give you better results.
my $pid;
if($pid = fork()) {
print(FOUT running ($pid)\n);
In my experience Perl on Windows does not handle the (Program = \foo)
case well at all. I have had better luck with the (Program = sub {
foo() }) case, but even that seems a bit iffy to me.
I'm still waiting for someone who can explain why sub{ foo() } sometimes
works when \foo doesn't.
into trying to get the
original patch right.
I'd really love understand why this code is needed (on not). So far all
of my tests have performed identically (other than the leak) with or
without the _SetStdHandle() calls.
-Andrew
Rocco Caputo wrote:
First, thanks to Andrew Feren, POE::Wheel
PerlSvc works fine with POE. I have several apps that use it.
Not sure about the cross compiling. At work we have both Win32 and
Linux application, but we build natively on each platform.
-Andrew
Andrew O'Brien wrote:
Hi Andreas,
I was trying to find a solution how to run POE
What version of POE are you running? I gather from your other email
that you are running on Win32.
Having the app work for a minute or so and then hang sounds suspiciously
like
https://rt.cpan.org/Ticket/Display.html?id=49379
-Andrew
Andreas Altergott wrote:
Hi,
my session is behaving
I've only read through the code so far, but here are a couple of thoughts.
I thought '' should be specified for unused EasyDBI aliases rather than
'not_used'. Although I like the self documenting nature of 'not_used'.
This seems straight forward enough and looks like what you advertised.
I
{
... }; if ($@) {... }
-Andrew
Andrew Feren wrote:
It's been a while since I looked at all of these. I have some code
using EasyDBI and other code using SimpleDBI.
Initially EasyDBI was the only one I could get to work on both Linux
and Windows. As of version 1.27 SimpleDBI also works on both
platforms
I've been starting to implement something similar so I'd love to see this.
-Andrew
Phil Whelan wrote:
Hi,
I like POE-Component-EasyDBI
Actually, I've written a wrapper module
POE-Component-EasyDBI-Multiplex, which I've not yet made public, but
we're using to manage a pool of EasyDBI
I don't use Tk, but I do use perlapp and POE. The attached script works
compiled with perlapp and as a vanilla perl script. (By works I mean no
more error messages when compiled. The script still doesn't *do*
anything ;-)
The important magic seems to be
use POE qw
13 matches
Mail list logo
