,
Markus
-Original Message-
From: Markus Jansen
Sent: Tuesday, July 16, 2013 5:57 PM
To: perl...@perl.org
Cc: Markus Jansen
Subject: Localizing %SIG in Safe.pm 2.{35,36,37} crashes POE::Wheel::Run ...
This is a bug report for perl from markus.jan...@ericsson.com, generated
: poe@perl.org
Subject: Re: FW: Localizing %SIG in Safe.pm 2.{35,36,37} crashes
POE::Wheel::Run ...
Hi all
Breaking out a Safe compartment is all about compiling code that will be
executed later. It happens that there are working exploits that use a
combination of %SIG and eval inside
(on CPAN, 2.{35,36,37} in Perl core) may be a
great step for security, but it unfortunatately spoils POE::Wheel::Run
(basically POE and all other asynchronous frameworks dealing with external
processes).
The symptom experienced is that your application might sooner or later crash
(reliably when
-
From: Markus Jansen
Sent: Tuesday, July 16, 2013 5:57 PM
To: perl...@perl.org
Cc: Markus Jansen
Subject: Localizing %SIG in Safe.pm 2.{35,36,37} crashes POE::Wheel::Run ...
This is a bug report for perl from markus.jan...@ericsson.com, generated with
the help of perlbug 1.39 running
Caputo [mailto:rcap...@pobox.com]
Sent: Tuesday, July 16, 2013 6:40 PM
To: Markus Jansen
Cc: r...@consttype.org; poe@perl.org
Subject: Re: Localizing %SIG in Safe.pm 2.{35,36,37} crashes POE::Wheel::Run ...
Thank you for the alert. Is there any reasonable way to work around this?
--
Rocco Caputo rcap
unless defined $next_task;
print Starting task for $next_task...\n;
my $task = POE::Wheel::Run-new(
Program = sub {cr_sub($next_task)},
StdoutEvent = task_result,
CloseEvent = task_done,
);
$heap-{task}-{$task-ID} = $task;
$kernel-sig_child($task-PID
defined $next_task;
print Starting task for $next_task...\n;
my $task = POE::Wheel::Run-new(
Program = sub {cr_sub($next_task)},
StdoutEvent = task_result,
CloseEvent = task_done,
);
$heap-{task}-{$task-ID} = $task;
$kernel-sig_child($task-PID
Couple of more issues resolved, this time regarding daemonization of POE
processes, see below. Thanks!
-- Mike
Mike Schilli
m...@perlmeister.com
-- Forwarded message --
From: p...@0ne.us p...@0ne.us
To: Mike Schilli m...@perlmeister.com
Subject: Re: POE::Wheel::Run
: !!! In extreme cases, your program can force a system reboot
7353: !!! if this resource leakage is not corrected.
although the code catches the sig_child:
use strict;
use warnings;
use POE;
use POE::Wheel::Run;
my $session = POE::Session-create(
inline_states
, in order to gracefully terminate the program you need to
delete the wheel in the sig_child event so the reference counts for
your session
will go down and POE::Kernel will commence shutdown. This is
explained somewhat in the POE::Wheel::Run docs. ( also in POE::Wheel too )
Here's
: 0
pid 19826 STDERR: ],
'POE::Driver::SysRW' ),
pid 19826 STDERR: undef,
pid 19826 STDERR: 'POE::Wheel::Run(11)
- select stdin',
pid 19826 STDERR
2009/10/13 Andrew Feren acfe...@yahoo.com
I'm not really sure, but I'd guess that the Daemon module isn't
copying/cloning something that it should. As a result
Win32::Daemon::StopService(); is getting called unexpectedly in a DESTROY or
END block when the child exits.
That is probably the
.
How did you use exec()? calling exec() after the fork() failed for me
in the same way as calling exit.
I did not try to run exec() from a fork. That's sad to hear, else one
could use Wheel::Run by setting the program to an array. This would run
exec() on line 443, instead of the final exit
state will get executed.
How did you use exec()? calling exec() after the fork() failed for me
in the same way as calling exit.
I did not try to run exec() from a fork. That's sad to hear, else one
could use Wheel::Run by setting the program to an array. This would run
exec() on line
I took some time at lunch today and got Win32::Daemon functional on my
system. I've attached a slightly hacked up version of your original
script that works with fork(). I would, however, suggest that
Olivier Mengué's work around described earlier in this thread is saner
than what I have
problem when
using POE::Wheel::Run::Win32 with Win32::Daemon as a windows service.
Your service will get a termination request from windows, as soon as any
child process terminates.
This happens because POE::Wheel::Run::Win32 is using the fork() method.
I do not know how exactly ActiveStates Perl
Hi,
Andrew Feren wrote:
Something like the following will give you better results.
my $pid;
if($pid = fork()) {
print(FOUT running ($pid)\n);
wait();
} else {
open(FOR, '', 'C:\delme-kid.txt');
thread();
close(FOR);
2009/10/9 Andreas Altergott alterg...@mira-consulting.net
Hi,
Hi Andreas
this will be especially interesting for dolman :-)
dolmen !
as already described in previous emails there is a big problem when
using POE::Wheel::Run::Win32 with Win32::Daemon as a windows service.
Your service
The question in my mind: If fork() is so troublesome on Windows, do we
have an alternative?
For the (Program = foo.exe) form, we can possibly avoid fork()
altogether. http://rt.cpan.org/Public/Bug/Display.html?id=48715#txn-659406
includes some code that promises to work well.
For the
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.
::Run::Win32 has been merged
into POE::Wheel::Run.
Andrew has also reported a memory leak POE::Wheel::Run under Windows:
https://rt.cpan.org/Ticket/Display.html?id=50068
My problem is that I don't know Win32 APIs well enough to say whether
his patch does any harm. He's bypassing
Win32
2009/10/2 Rocco Caputo rcap...@pobox.com
First, thanks to Andrew Feren, POE::Wheel::Run::Win32 has been merged into
POE::Wheel::Run.
Great news !
I'm using POE::Wheel::Run::Win32 with my patch for bug #43995
https://rt.cpan.org/Ticket/Display.html?id=43995
Looks like you applied the patch
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::Run::Win32 has been
merged into POE::Wheel::Run
First, thanks to Andrew Feren, POE::Wheel::Run::Win32 has been merged
into POE::Wheel::Run.
Andrew has also reported a memory leak POE::Wheel::Run under Windows:
https://rt.cpan.org/Ticket/Display.html?id=50068
My problem is that I don't know Win32 APIs well enough to say whether
his patch
There has been an issue on some systems (Linux, it seems) where
POE::Wheel::Run doesn't emit a CloseEvent for children behind a pty or
pty-pipe conduit. Philip Gwyn provided test cases for this, and we
were able to make a fix. POE's repository has it now, and you can get
a copy to try
Jonathan S. Polacheck (Wed 03/25/09 14:56):
I am trying to concoct and script that will take a binary data stream from
tcpdump, feed it into a filter, then in another instance of wheel::run,
hexdump the data stream from the filter. The code I have come up with so
far is in the 6th entry
I am trying to concoct and script that will take a binary data stream from
tcpdump, feed it into a filter, then in another instance of wheel::run,
hexdump the data stream from the filter. The code I have come up with so
far is in the 6th entry in the Continuous packet capture thread. I
cannot
Hello,
I am a newbie to POE. I want to know the difference between using
POE:wheel::run on win32 vs using POE::wheel::run::win32. I am currently
using POE::wheel::run on a win32 system to start a new .NET process, but I
the perl process dies after the .net console app exits. Are there any
to make a non-blocking call to a
function in
an external Perl package which takes Perl reference data structures.
To be honest, I don't know. But if Perl can do it, why wouldn't
POE::Wheel::Run?
--
Rocco Caputo - [EMAIL PROTECTED]
Rocco,
Any ideas on how we might fix POE::Wheel::Run? The only one I can think
is to fix the win32 implementation of fork(), which does not sound fun
considering I know very little about the Perl internals.
Jeremy
Rocco Caputo [EMAIL PROTECTED] 2/07/2007 14:31
Jeremy: A documentation update
wrote:
Rocco,
Any ideas on how we might fix POE::Wheel::Run? The only one I can
think
is to fix the win32 implementation of fork(), which does not sound fun
considering I know very little about the Perl internals.
Jeremy
Rocco Caputo [EMAIL PROTECTED] 2/07/2007 14:31
Jeremy
Yes using Win32::Process
(http://search.cpan.org/~jdb/libwin32-0.27/Process/Process.pm).
However the only way to start the process in a non-blocking manner is
to detach the process. Once that happens I do not think it is possible
to gain access to the stdin, stdout and stderr...
Jeremy
Rocco
Have you tried http://search.cpan.org/~bingos/POE-Wheel-Run-Win32/ ?
I have heard it doesn't use fork(), but I haven't used it.
--
Rocco Caputo - [EMAIL PROTECTED]
On Jun 26, 2007, at 20:29, Jeremy Palmer wrote:
On 6/24/07, Jeremy Palmer [EMAIL PROTECTED] wrote:
The Win32 fork emulation
On Wed, Jun 27, 2007 at 05:06:49AM -0400, Rocco Caputo wrote:
Have you tried http://search.cpan.org/~bingos/POE-Wheel-Run-Win32/ ?
I have heard it doesn't use fork(), but I haven't used it.
It still uses the fork().
--
Chris Williams
aka BinGOs
PGP ID 0x4658671F
http
[EMAIL PROTECTED]
Sent: Monday, June 25, 2007 2:04 PM
To: Zack Payton
Cc: poe@perl.org
Subject: Re: Win32 Wheel::Run Issues (Reformated)
Hi Zack,
Yes I have a resent version of POE installed from CPAN. Version
0.9917.
Thanks
Jeremy
Zack Payton [EMAIL PROTECTED] 26/06/2007 07:08
Jeremy,
I assume
references to Perl objects and array references (however no subroutine
refs).
I've looked at the options for completing this sort of task with
POE::Component::Child Wheel::Run + Filter::Reference, however there
seems to be one limiting factor here - Win32 fork emulation.
The Win32 fork emulation seems
in an external Perl package. This function takes references to
Perl objects and array references (however no subroutine refs).
I've looked at the options for completing this sort of task with
POE::Component::Child Wheel::Run + Filter::Reference, however there seems
to be one limiting factor here
There is a limitation within win32 limits a single process from creating
more than 64 processes, however, there is nothing to limit the processes
that you create from creating their own child processes. With a little
hackery you could use master slave model in which the master creates slaves
Hi Zac,
There's no problem with creating multiple processes from the
CreateProcess() function. I've created 1000's of child processes from
this API call without issues in the past.
I think the issue relates to the way the win32 fork function is using
the win32 threads. On WIN NT4 based OS's
::Component::Child
Wheel::Run + Filter::Reference, however there seems to be one limiting factor
here - Win32 fork emulation. The Win32 fork emulation seems very buggy. In
tests I've used with Wheel::Run I get fork failures (i.e. fork() failed:
Resource temporarily unavailable) after the 64 calls
Great catch, Eric. POE::Wheel::Run *is* flawed for assuming $/ is the
default value. I don't object to ensuring it's locally the default around
$sem_pipe_read.
--
Rocco Caputo
On 3/16/07 16:33, Eric Busto [EMAIL PROTECTED] wrote:
Last e-mail, I promise.
I found the source of the problem
, so any opposition to POE::Wheel::Run
setting $/ itself?
-Original Message-
From: Eric Busto
Sent: Thursday, March 15, 2007 2:09 PM
To: poe@perl.org
Subject: RE: :Wheel::Run-new not returning?
So by running my script like so:
PERLDB_OPTS=NonStop=1 LineInfo=debug.out AutoTrace
/home
Man, I hate to keep replying to myself. :)
I modified the code in POE::Wheel::Run a bit to set an alarm before
trying to read $sem_pipe_read. Interestingly, it triggers now and then.
Here is the addition:
Line 545 of Run.pm:
# Wait here while the child sets itself up.
eval {
local
I'm using POE::Wheel::Run to spawn off child rsync processes. Every so
often (i.e. every 1 in 50 to 100 calls), the new method fails to return.
Since it seems a bit random, I'm stumped on how to go about figuring
this out. Has anyone else encountered this before, or have any ideas?
I'm
Hi all,
I'm using Wheel::Run in my script. It works fine in the foreground. But
when I daemonize it,
the last thing executed is the CHLD signal handler. It seems to exit
normally, without core dump or anything abnormal (but there should be
more code after).
That description doesn't tell much, I
I don't seem to get POE::Wheel::Run working with a subroutine.
It's emitting text to STDOUT, which should trigger a captured event
in POE. Do you know why the script below never reaches the
captured state?
2006/06/04 21:36:44 child sleeping
2006/06/04 21:36:44 done printing
use POE qw(Wheel
:
+--
| I don't seem to get POE::Wheel::Run working with a subroutine.
|
| It's emitting text to STDOUT, which should trigger a captured event
| in POE. Do you know why the script below never reaches the
| captured state?
|
| 2006/06/04 21:36:44 child sleeping
| 2006/06/04 21:36:44 done printing
last night puzzling over exactly this, this
morning the answer came to me in a pre-waking thought. What a waste
of neurons, others have asked and answered the problem for me :-)
I think it's worth a mention of this on the POE::Wheel::Run man page,
the example given specifically does *not* save
On Tue, 6 Jun 2006, Justin Hawkins wrote:
Ha!
I spent several hours last night puzzling over exactly this
Thanks, I appreciate your help :). So obvious in hindsight, but
really hard to figure out without helpful error messages.
-- Mike
Mike Schilli
[EMAIL PROTECTED]
Apologies in advance that this post has got a bit longer than I expected
when I started ...
I'm using Wheel::Run to run a program in a child process and catch stdout
and stderr. This works fine when the program is run in a terminal, but
when I daemonize it using Proc::Daemon, something strange
On 08-Sep-2005 Hicks, Matthew wrote:
(Anyone got a suggestion other than using SSH+tail to watch a
restricted access remote file?)
Why yes! How about FollowTail + IKC and an ssl tunnel?
-Philip
Hicks, Matthew wrote:
Daemonizing is something you do with your program *before* you start
POE.
I daemonize before creating any sessions or calling kernel-run().
I do daemonizing all the time. start program, daemonize, start poe.
use wheel::run all you want.
Super! Do you have
Honestly, from here it looks like you're either doing it
wrong, or there
is an issue I'm quite ignorant of (VERY possible :). But if
all you're
trying to process is tail(1), then use POE::Wheel::FollowTail and
hopefully you'll sidestep the problem.
I started with POE::Wheel::FollowTail
it with inetd and a script I was dealing with. My POE
script opened SSH using Wheel::Run, and told ssh to do this loop:
while :; do uptime; sleep 3; done
If my script exited, the SSH would stay behind!
My first solution was to turn the output of what I was getting via
uptime into a POE script. (so
than using SSH+tail to watch a
restricted access remote file?)
YES. I did it with inetd and a script I was dealing with. My POE
script opened SSH using Wheel::Run, and told ssh to do this loop:
while :; do uptime; sleep 3; done
If my script exited, the SSH would stay behind!
That's
to watch
files, consider using POE::Wheel::Run and your operating system's native
tail utility instead.'
Opening STDIN to /dev/null (as both the daemonizing modules do) seems to
break tail--or at least Wheel::Run's ability to read from a spawned
tail. Since, ls and a few other commands had
Daemonizing is something you do with your program *before* you start
POE.
I daemonize before creating any sessions or calling kernel-run().
I do daemonizing all the time. start program, daemonize, start poe.
use wheel::run all you want.
Super! Do you have sample code for a daemon
On Sep 7, 2005, at 16:58, Hicks, Matthew wrote:
Rob Bloodgood wrote:
Why or how is this breaking for you?
The behavior I see (in my Solaris 8 9 environment) is that if STDIN
reopened from /dev/null (which the daemonizing modules do) then a
POE::Wheel::Run spawning a tail command returns
I'm writing a program that can run interactively, or as a daemon. It
spawns a few sessions with POE::Wheel::Run that work fine interactively.
If I call Proc::Daemon::Init, the wheels generate a single error
signal--operation: read, errnum: 0, errstr: blank--then a .
Is this a side-effect
If I call Proc::Daemon::Init, the wheels generate a single error
signal--operation: read, errnum: 0, errstr: blank--then a .
this should read:
If I call Proc::Daemon::Init, the wheels generate a single error
event--operation: read, errnum: 0, errstr: blank--then a closed
event.
::Wheel::Run forked processes (any forks,
actually, but at the moment I'm using POE::Wheel::Run).
While debugging this, I discovered that forking doesn't matter. The
problem occurs if a client session doesn't exit promptly.
I did some hunting through the Sever::TCP code, looking for why
Hi all,
Firstly, since I'm a new POE user I'd like to greet everyone here and
thank the folks responsible for POE. What a fine piece of work!
I'm having a small issue with POE::Component::Server::TCP, when used
in conjunction with POE::Wheel::Run forked processes (any forks,
actually
On 13 Apr 2005, at 04:53, Rocco Caputo wrote:
1. The exit() in POE::Wheel::Run doesn't bypass forked object
destruction. With ASSERT_DEFAULT on (the default for POE's tests), a
lot of this thing leaked messages show up. They're harmless, more
or less, but object destructors are still being
Quoting Rocco Caputo ([EMAIL PROTECTED]):
How's that going? I've been tracking the problem down on and off
today, but no luck. Some notes:
1. The exit() in POE::Wheel::Run doesn't bypass forked object
destruction. With ASSERT_DEFAULT on (the default for POE's tests), a
lot of this thing
Quoting Arthur Bergman ([EMAIL PROTECTED]):
On 13 Apr 2005, at 04:53, Rocco Caputo wrote:
1. The exit() in POE::Wheel::Run doesn't bypass forked object
destruction. With ASSERT_DEFAULT on (the default for POE's tests), a
lot of this thing leaked messages show up. They're harmless, more
need to fork() for Wheel::Run?
Because code written using current Wheel::Run assumes parallelism. Do
you mean 'why aren't we using CreateProcess'? Because it seemed
simpler/less-maintenance to keep the code base as similar as possible
between the two different architectures. And you need to do
On 13 Apr 2005, at 12:47, Nick Williams wrote:
Hmmm.. to be honest I haven't actually touched the win32 code at
all...
What is the specific reason we need to fork() for Wheel::Run?
Because code written using current Wheel::Run assumes parallelism. Do
you mean 'why aren't we using CreateProcess
Quoting Arthur Bergman ([EMAIL PROTECTED]):
Knowing parts of the internals that the fake process environment uses I
would strongly recommending on just using CreateProcess ;-). It is also
quite wasteful to use fork() for this since unlike unix it will
actually copy all your memory over
On 13 Apr 2005, at 16:13, Merijn Broeren wrote:
But we cannot use CreateProcess with a coderef, at least I don't see
how. The issue is with a coderef, what to do when it dies, we want to
kill of the thread but not fire destructors. Kill will work, but
maybe leave memory around.
When trying with
Hi,
My collegue Nick Williams and I had a stab at making POE::Wheel::Run
work on Win32. The attached patch makes it work with both code refs
and external programs, all regression tests pass, after adjusting the
wheel_run.t to not die anymore and use the correct commandline
quotation.
The patch
On Mon, 11 Apr 2005, Bas Schulte wrote:
On maandag, apr 11, 2005, at 16:03 Europe/Amsterdam, Merijn Broeren
wrote:
My collegue Nick Williams and I had a stab at making POE::Wheel::Run
work on Win32.
Isn't that like trying to sail the ocean in a bathtub?
Yes, but it's so nice
On Thu, Dec 23, 2004 at 04:03:11PM -0800, Dan McCormick wrote:
I briefly considered whether the wheel should guarantee flushing on
shutdown, but I decided against it. Sometimes people may want to shut
down a client regardless of the input waiting for it.
Maybe the shutdown methods need
take a stab at documenting get_driver_out_octets
and get_driver_out_messages in POE::Wheel::Run (or POE::Wheel?) since they
aren't mentioned anywhere?
I'd greatly appreciate doc patches. I think nobody looks at
POE::Wheel, so the methods probably ought to be documented in each
subclass.
I briefly
I briefly considered whether the wheel should guarantee flushing on
shutdown, but I decided against it. Sometimes people may want to shut
down a client regardless of the input waiting for it.
Maybe the shutdown methods need flush/immediate options?
That would definitely be convenient.
get_driver_out_octets
and get_driver_out_messages in POE::Wheel::Run (or POE::Wheel?) since they
aren't mentioned anywhere?
Dan
On 12/21/04 9:57 PM, Rocco Caputo [EMAIL PROTECTED] wrote:
On Tue, Dec 21, 2004 at 08:39:53PM -0800, Dan McCormick wrote:
So consider this:
I have a stream of data, which I'm
On Mon, Dec 20, 2004 at 10:44:23PM -0800, Dan McCormick wrote:
Shouldn't the code below print 1, 2, 3, 4 on separate lines to the file
/tmp/test.txt?
If I comment out lines 537-538 of POE::Wheel::Run.pm, namely:
$poe_kernel-select_pause_write($self-[HANDLE_STDIN])
unless
Hmmm. Interesting.
So consider this:
I have a stream of data, which I'm sending to the POE::Wheel::Run process.
At an arbitrary time I can get a signal that the stream has ended, at which
point I want to shutdown the process's STDIN.
If I knew the last bit of data sent was going to be the last
need the
'doit' and 'shutdown' events to be separate (i.e., combining everything into
the _start event doesn't work). Is that behavior intentional?
Thanks,
Dan
#!/usr/bin/perl
use strict;
use POE qw(Wheel::Run);
POE::Session-create(
package_states = [
main = [qw( _start _stop doit
you might also want to look at PoCo::Child for inspiration
-Original Message-
From: Andy Levine [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 09, 2004 3:23 AM
To: [EMAIL PROTECTED]
Subject: RE: small wishes to poe::wheel::run can't figure out.
Michael,
I would like to get
Michael,
I would like to get an error_level for each program i run in parallel...
Pass the param ErrorEvent when you instantiate the POE::Wheel::Run to trap
errors.
And it would also be nice to get a value back so i can track which program
that return a
given answer...
I get program exit
use warnings;
use strict;
use POE;
use POE::Wheel::Run;
my $time1=time();
# Start a multitasking session to manage several child processes. Map
# each event to a function which will handle it. Run POE::Kernel,
# which manages the session's activity. run() will return when the
# session is done
Hello again, seams I'm having problems...
I'm trying to use DBI, but can't use the DBI components, becuase getting them into
this place will take longer than my deadline, so trying to impliment my own DBI code
used from POE...
I have a POE session that makes a connection via DBI to Sybase and
::Run::new(/sbcimp/run/pkgs/CORE/11.2.0/links/cpan/lib/POE/Wheel/Run.pm:378):
378: close STDOUT if defined fileno(STDOUT);
DB2
POE::Wheel::Run::new(/sbcimp/run/pkgs/CORE/11.2.0/links/cpan/lib/POE/Wheel/Run.pm:379):
379: close STDERR if defined fileno(STDERR);
DB2
POE::Wheel
Hi,
I have made a small patch against POE 0.27 which let you set the
window size for a pty for a process started with POE::Wheel::Run.
Unfortunately my first patch does not work correctly when STDIN isn't tty.
Here is an updated version of the patch, which also does the right thing,
when
On Fri, Jul 25, 2003 at 10:38:45AM -0500, Shawn Edwards wrote:
I have some programs that I'd like to run via Wheel::Run. These potential
client apps read all of their input from stdin, and when stdin closes,
process the input, spew output, and close.
[...]
I've implemented a shutdown_stdin
How is the status of support of wheel::run on win32. Or some work around?
Thanks
On (11/10 08:20), PerlDiscuss - Perl Newsgroups and mailing lists wrote:
How is the status of support of wheel::run on win32. Or some work around?
broken. and probably will stay that way until someone quite godlike
fixes fork+exec on windows
__
Matt Cashner
http://eekeek.org
eek at eekeek.org
I have some programs that I'd like to run via Wheel::Run. These potential
client apps read all of their input from stdin, and when stdin closes, process
the input, spew output, and close.
The problem I'm having is that I'm not finding a way to close stdin for the
child process under Wheel
On Fri, Jul 25, 2003 at 10:38:45AM -0500, Shawn Edwards wrote:
I have some programs that I'd like to run via Wheel::Run. These potential
client apps read all of their input from stdin, and when stdin closes,
process the input, spew output, and close.
The problem I'm having is that I'm
On Tue, Mar 25, 2003 at 10:37:19PM +0100, Sebastian Freund wrote:
Dmitri Tikhonov wrote:
Good luck, it can take you a while to find all the leaks, but it can be
done.
I want to believe! ;-) Could you help me, please?
I can't see anything obviously wrong in the bits of code you posted.
Is
On Fri, Mar 28, 2003 at 09:03:54PM +0100, Sebastian Freund wrote:
Hi!
Rocco Caputo wrote:
I can't see anything obviously wrong in the bits of code you posted.
Is it possible for you to post a small yet complete and runnable test
case that exhibits the problem?
Yes, of course.
The
I think that your interpreter is having problems freeing memory associated
with closures. I ran into this before, and what I had to do is to patch
POE so that POE::Wheel::Run accepts arguments. Check it out here:
http://rt.cpan.org/NoAuth/Bug.html?id=1783
(the patch is against version 0.22
On Mon, Mar 24, 2003 at 11:15:52AM -0500, Dmitri Tikhonov wrote:
I think that your interpreter is having problems freeing memory associated
with closures. I ran into this before, and what I had to do is to patch
POE so that POE::Wheel::Run accepts arguments. Check it out here:
http
Hi,
I'm going to use POE::Whel::Run in a system monitoring tool.
I implemented a cron-like functionality to start up periodic measurements,
but I've encountered a serious resource leak: Along with every
creation/destruction of POE::Wheel::Run the RSS of the monitoring process
increased
I think it's an interesting feature, but I don't use Wheel::Run enough
to know how generally useful it is. I'm looking for more discussion
on it before making any decisions.
I think it's fairly useful. I've implemented it in PoCo::Child but was
hoping to hear the other ideas Robert mentioned
Rocco Caputo wrote:
On Thu, Mar 06, 2003 at 11:00:26AM +1100, [EMAIL PROTECTED] wrote:
I understand that there is a long-term goal to supercede POE::Wheel::Run
with a component module with the tentative title of POE::Component::Process
(http://poe.perl.org/?V1.0-TODOS) and there has been
I understand that there is a long-term goal to supercede POE::Wheel::Run
with a component module with the tentative title of POE::Component::Process
(http://poe.perl.org/?V1.0-TODOS) and there has been a discussion on the
mailing list previously about how the POE::Wheel::Run module could
some simple additions to the POE::Wheel::Run module
I'm interested in what other changes beyond the directory argument you have
in mind. I've implemented the chdir feature in PoCo::Child which is a layer
on top of Wheel::Run and would be interested in whatever improvements you or
anyone might
On Thu, Mar 06, 2003 at 11:00:26AM +1100, [EMAIL PROTECTED] wrote:
I understand that there is a long-term goal to supercede POE::Wheel::Run
with a component module with the tentative title of POE::Component::Process
(http://poe.perl.org/?V1.0-TODOS) and there has been a discussion
Rocco Caputo wrote:
On Wed, Feb 12, 2003 at 08:38:25AM +1100, [EMAIL PROTECTED] wrote:
snip
It's a valid interpretation of ErrorEvent, but it's not the way
POE::Wheel::Run was written.
StdoutEvent, StderrEvent, and ErrorEvent refer to the pipes that
attach the parent and child processes
1 - 100 of 136 matches
Mail list logo
