POE::Component::Client::TCP can take an Alias parameter and it will set
this alias onto the session on startup of the Session. It does not set
the alias on reconnect. However, whenever the shutdown state is entered
(e.g. connection dies), it removes the alias. Which means you have to
manually
Scott wrote:
[...]
If you're really only storing data, you really should use an object OR
package in the ways I mentioned above. Atleast, if you have any
desire to maintain efficiency.
Now here I must note, that I didn't come up with the idea of removing
inter-session calling all together.
Scott wrote:
Nick Williams wrote:
Scott wrote:
[...]
If you're really only storing data, you really should use an object
OR package in the ways I mentioned above. Atleast, if you have any
desire to maintain efficiency.
Now here I must note, that I didn't come up with the idea of
removing
Taking Chris' question further... why not implement wait queues (I'm
thinking along the lines of NT). Any session could declare it's interest
on a waitable object... and anyone with a reference to that object could
call wakeup on it. SIGCHLD handling is therefore just a special
case of this - you
Rocco Caputo wrote:
On Mon, Feb 16, 2004 at 04:58:42PM -0600, Luke A. Kanies wrote:
Is
there a stop analog to $poe_kernel-run()?
Yes. An experimental stop() was introduced in version 0.28.
Most cool! I didn't know about this until now - I've just switched over
to using it and it
In your code snippet, despite what you print out, you're not actually
changing $heap-{nick}, so you're reconnecting with the same name as
before...
Nick.
On Sun, 18 Apr 2004, Ciro wrote:
Psilon, my modular POE IRC bot, is coming along fairly well. I've run
into a bit of a snafu though. If
Chris Fedde wrote:
On Tue, 10 Aug 2004 07:59:03 -0600 Wiggins d Anconia wrote:
+--
| I'll add another. I think at the very least POE (with the 'E')
needs to
| stay intact. I know the chatting convention has been to use 'PoCo',
| but to keep the two related I think the full
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
Arthur Bergman wrote:
On 13 Apr 2005, at 11:49, Merijn Broeren wrote:
kill 9,$$; :-)
Did you fix that then? The perlfork manpage makes it sound like there
will be leaks all over the place.
Hmmm.. to be honest I haven't actually touched the win32 code at all...
What is the specific reason we
A strange one, so I'd like to solicit some opinions :-).
Client::TCP starts up with a 'server' wheel stashed away in the heap as
a POE::Wheel::SocketFactory while it's waiting for the connection to
occur. Once the connection is successful, it changes it's {server} in
the heap to be a
The normal disconnection happens if the server closes the socket without
error. So, your server is immediately closing the socket after sending
the reply. This means that if you treat that as a failure and try to do
the same thing again, you'll get exactly the same behaviour each time.
You
So, I've found the reason that recent releases of POE cause me to get
memory leaks - I know others have had problems also, so I wanted to get
an open discussion of what I'm being bitten by and possible ways to
workaround this.
It turns out for me that my sessions aren't being garbage
that
far).
Nick.
-Mathieu
--- Nick Williams [EMAIL PROTECTED] wrote:
So, I've found the reason that recent releases of POE
cause me to get
memory leaks - I know others have had problems also, so I
wanted to get
an open discussion of what I'm being bitten by and
possible ways
', 'do_something');
that will now increment the reference count of the session and therefore
make that session persistent until the signal handler is deleted via
something (and note, not within the _stop event, since we don't get that
far).
Nick.
-Mathieu
--- Nick Williams [EMAIL PROTECTED] wrote
Rocco Caputo wrote:
Do you have a use case where it's impossible to do something under
the new behavior? I'm working under the assumption that a session
can always find a way to call sig(YOUR_SIGNAL_HERE = undef) when
it's ready to be destroyed.
When it's ready to be destroyed is the
Firstly, thanks for the in-depth reply! Some thoughts interleaved below...
Rocco Caputo wrote:
On Aug 22, 2006, at 14:06, Nick Williams wrote:
Rocco Caputo wrote:
Do you have a use case where it's impossible to do something under
the new behavior? I'm working under the assumption
Rocco Caputo wrote:
Attached as a gzipped text file. Sorry for posting a binary, but I
couldn't pass up the 3:1 compression. Please quote relevant parts of
the discussion if you want to comment on things. Total time to cull
and clean this, about 90 minutes.
I hope it explains the
lanas wrote:
Folks,
Using POE::Component::Client::TCP, I want to send several short
messages to a server. The server expects each message as a
stand-alone message so that it knows that the first byte is a command,
the second 4 four bytes a data length, etc...
But when I send 4 short
I now have a new problem (don't I always ;-).
ReadLine has a modification that I didn't spot earlier (due to our
inability to use the last few releases) that doesn't make sense to me.
The change labelled r2098 (which went into 0.37, I believe) does this:
2006-09-05 01:41:11 (r2098) by
Regarding the passing of the socket into clientconnected - I've wished for
this in the past, in order to be able to modify TCP options on the socket,
which didn't seem possible in the past... It would be nice if that was
possible to get at this (either via some available API which I just haven't
20 matches
Mail list logo
