[most important points first]
> In your case, I would create a single persistent POE::Session instance
> that serviced all the watchers.
I would, too, but I cannot find a way to do that with POE: sessions
without active watchers will be destroyed, forcing the session to have
active resources will make the program never-ending.
I already told you that I tried this approach, and why I couldn't get it
working.
You kepe repeating how it could be designed better, but you never actually
say how to solve the fundamental problems and bugs within POE that keep it
from being implementable.
As I said, if possible, I can only imagine the design becoming vastly more
complex because I would have to create sdessions on demand and be able to
react to my session beign turned down at unopportune times.
What we seem to agree on by now is that such a design is not trivial to do
with POE.
Also, remember that the benchmarks show that session creation is not
the big problem, running the sesions is - of course, there could be
inefficiencies in POE handling large number of sessions, but that means
just that - POE doesn't scale well.
On Mon, Apr 28, 2008 at 04:36:42AM -0400, Rocco Caputo <[EMAIL PROTECTED]>
wrote:
> Most people on the planet don't know Perl, or even how to program a
> computer. No amount of documentation will help them. :)
Good (or any) documentation is widely known to be almost a _requirement_
for learning how to program or use a software package.
> In the future, you may wish to include me on your list of people to
> consult about designing applications for POE. I may known a thing or
> two about the topic. :)
I am not interested in designing applications for POE - I am interested in
making it possible to write event-based modules that are interoperable
between various event loops such as POE.
As the documentation mentions, AnyEvent doesn't enforce itself on a
module, unlike POE - a module using POE is not going to work with other
event loops, because it monopolises the process.
This means that a module using POE forces all its users to also use POE.
AnyEvent does not do that, as long as it supports the event model actually
in use (it is not an event loop itself!): A module that uses AnyEvent
works with both Qt, POE, IO::Async (once its backend is implemented), EV
and so on.
This is a fundamental difference between POE and AnyEvent, it has nothing
to do with event loop backend modules, of which POE also emplys a few, but
comes form the fact that you have to call POE::Kernel->run and give up
your process to it (just like with EV::loop etc.)
> Are you aware that I'm gradually rewriting POE's documentation? If
> you could describe what you don't like in a useful way, I may be able
> to do something about it.
Since I described it already (and you know that) it means you find the way
I did it "not useful". Thats a strawman argument. If you don't like my
criticism or don't understand it, ask.
> I would love to have the opportunity to suggest a different design,
You always ahd the opportunity, you are not using it.
> Obviously I cannot expect you to know everything about POE. Likewise,
> you cannot expect me to magically know when you started writing
> AnyEvent::Impl::POE.
It doesn't matter when I started writing AnyEvent::Impl::POE at all. What
matters is that you made unfounded (and as you now admit, wrong)
statements about it (and its author).
It is fine with me if you don't understand AnyEvent, it is somewhat fine
with me if you make strong (But wrong) statements about it, but don't
expect anybody to put much faith in them, or you ability to make useful
statements.
> Even if you announced it somewhere, I may not have been looking. The
> first I heard of it was here, when you announced your benchmarks.
Yes, so?
> In general, if you need someone's attention online, the most effective
> and polite way is to contact them directly.
I did not need your attention?
> about this, then I'm sorry that I missed it. Are you sure your
> message wasn't lost in transit?
Which message? I was only conveying some benchmark results, to give
people an idea of the overheads of AnyEvent of various event loop
implementations in the hope of beign useful.
I was also hoping that people might give AnyEvent some try, as it's design
doesn't force a module author using it into a specific event loop.
> Assuming that N is the same between the equivalent POE and
> AnyEvent::Impl::POE program:
>
> S(N*M) > S(N) for M > 1.
>
> QED :P
I couldn't really follow you here, and I am not sure what you have proven. To
me it certainly looks as if it was "POE cannot support the AnyEvent API
efficiently" (at leats not in a simple and straightforward way).
I knew that already.
> >I can only imagine making some very complex on-demand instantiating and
> >re- check wether the session still exists on each watcher creation.
>
> Your imagination comes up with such incredible things. Don't lose
> that. :)
Overbearing words after being wrong before.
> The "trick" is to minimize the number of sessions used.
I already said that, and explaiend why it didn't work.
> that sessions imposed overhead. I wrongly assumed the solution would
> be obvious.
Yes.
> I use this design in POE::Stage.
Does it survice multiple run's? If yes, how so?
> experimental code, you can find it on the CPAN. It also does a lot of
> other, unrelated things, so you may have difficulty separating the
> magic you need from the voodoo you don't.
As I said, less magic and vodoo and better documentation could be more
helpful in the long run.
I don't see how POE::Stage solves the problem of multiple run's stopping
sessions. If it does, couldn't you just advise me on how to do it insteadf
of referring to bugloads of other code? Either you know how to solve the
issues, then just tell us, or you don't, in which case going through large
amounts of code won't help.
> I won't blame you. But I will point out that your documentation says
> you're already familiar with using undocumented POE features. :)
Yes indeed :/
> >Instead of going around and accuse people of making bad designs, it
> >would be much better to improve the documentation for POE, so that said
> >people don't have to go around and start guessing...
> I don't appreciate your vague, negative comments about the
> documentation. Please describe problems in a useful way, or your
> expectation that they be fixed is unreasonable.
I did, in a long document that you admit having read already. If you don't
find the comments useful, thats your problem - you could aks me to clarify
them, for example.
_I_ don't appreciate your continuous implications that my comemnts were in
some way flawed without every mentioning a single piece of evidence.
> You seem to be saying that your design for AnyEvent::Impl::POE is
> based on guesswork.
Yes.
> If so, I overestimated your knowledge of POE based on your
> documentation.
I have no idea how you estimate my knowledge. I also fail to see what my
person has to do with anything.
> Therefore, please consider the chance that you may know less about POE
> than your documentation implies.
If there is any meaning in this sentence, it escapes me. I quited examples
form the documentation and explained all my arguments. It doesn't matter how
much I know or imply to know, as I *explain* the reasons behind what I said.
That is in stark contrast to you - you only ever imply the documentation
is rude, the module is fundamentally flawed, the comments are not useful
etc., without ever trying to solve the problems with POE that lead to this
design and the comments, and which are explained clearly.
> >Oh, and while you fix the docs, could you fix the other bugs as well
>
> I certainly can, but you'll need to describe them in a useful way
Done a long time ago and given to you. It might not be in a form that you
like, but it is doubtless that they are useful.
> >(the race condition with sigchld is really annoying,
>
> Please describe the race condition in a useful way, so that I can
> investigate and possibly fix it.
Again the red herring "useful" - it obviously was useful enough for other
people to understand the issue. The problem is that rgeistering a watcher
after the child process already exited causes POE to introduce a delay in
reapign the child (it does seem to do polling to do so, and seems to do so
once per second, so the delay is at most a second, still, thats a pretty
long time).
> POE checks for child processes between calls to application code. If
> you fork your process and set sig_child() in the same event handler,
> POE won't be able to call waitpid() between them. If this is the race
> condition you mean, then it simply shouldn't be possible.
The race condition is quite simple:
1. fork
2. child exits
3. parents gets sigchld (but no sigchld handler is registered yet)
4. sigchld watchers gets created
[time passes, POE select's many times without noticing the child exit]
5. POE eventually waitpids and finally detetcs the child
> On the other hand, I haven't actually documented this behavior. It
> hadn't occurred to me because all my programs follow the reliable
> pattern.
I have no clue what you mean, but POE ahs to support it, just as with any
other event loop - you cnanot tregister a child handler BEFORE you fork
because you don't know the pid. You cannot guarantee that the child exits
only afetr you registered the watcher, so POE has to deal with it already
having exited.
AnyEvent and EV certainly deal with this issue cirretcly and don't miss
the child exit.
> "Programs that wish to reliably reap child processes should be sure to
> call sig_child() before returning from the event handler that forked
> the process. Otherwise POE::Kernel may have an opportunity to call
> waitpid() before an appropriate event watcher has been registered."
No, it is a race in POE, not something the application can do anything
about.
> In the event that you've found an actual bug, I regret that your
> description of the problem is not useful.
Well, I can declare anything I want "not useful" - if you are incapable of
understanding, you should ask - I don't know how wlel your knowledge is
w.r.t. to process handling on unix, and I cannot write full novels and
programming manuals just in case I need to cover something you don't
understand.
> <purl> Look buddy, doesn't work is a strong statement. Does it sit on
"doesn't work" is certainly not how I described it.
> >and the nag messages are as well).
>
> I understand from your documentation that you dislike the "ugly" "nag"
> messages. I'm sorry, but I cannot help you there. They were added as
> the result of useful feedback from other users. And contrary to your
> documentation, they can be silenced.
Possible, but it is not documented (yes, run silences them, but it has
other undesirable effects as well, which is documented by AnyEvent's
adaptor module).
> The "run() method was never called" message can be silenced by calling
> run(). Not all applications require run(). But if you call it
> without any POE::Session instances, it will return immediately and
> satisfy POE::Kernel.
This is impossible it guarentee from within AnyEvent.
So there is no way to silence just the message.
> While this does not:
>
> perl -wle 'use POE; POE::Kernel->run; POE::Session-
> >create(inline_states => { _start => sub{} });'
As I said, for design reasons, Anyevent doesn't enforce itself on its
users, so the requirement to call ->run is not implementable.
AnyEvent::Impl::POE already invokes the run workaround in its manpage, and
why it is undesirable. This puts an unecessary burden on the user, and is
certainly an issue.
> I hadn't considered to document the technique because it seemed
> obvious to me.
It is obvious to me. But there is now ay to do that from within a module:
a module has no control over when it was loaded.
It is just one of the many small design issues (some of which I
documented) that make it very hard to use POE in a generic way.
I don't claim more, I don't claim less.
> obvious to me than are actually obvious to the average user. You
> should probably call them to my attention if you'd like them to be
> documented.
I only need a way to silence them withotu potentially freezing the
program, clearing the event queue, stopping running sessions etc.
> Speaking of which, I added this to the docs. Please let me know how/
> if I can improve it:
No amount of documentation can improve this, it is a problem within the
POE code.
> You complain about a message that occurs when a program leaks a child
> process. Programs that leak processes are broken in a way that is
> difficult to detect without the warning. In extreme cases, process
> leakage can quietly strangle a machine to death.
No, I complain about the emssage complaining about POE reaping a child. No
leak is involved anywhere, and nothign will "quietly" "strangle" anything
to death.
> POE can detect this silent but deadly condition.
There is nothing deadly about it.
> If you receive this message, it can be silenced by fixing the process
> leak.
... which is nonexistant.
> >Not sure why it would be a courtesy to me, do you have anything to
> >hide
> >or do you want to insult me even more in private so nobody sees your
> >real
> >self or something? (just guessing... :)
>
> Wow, you really do expect the worst from me. I don't know where that
> came from.
I expect you to back up your statements you made publicly (and in
private). As I told you before, it *is* bad (or worse) to make statements
without backing them up.
> The courtesy to you would be that I brought the issues to you
> directly.
It would be, if you had done that. But in private you just insulted
me more directly, but despite reqpeatedly askign you how to solve the
probelms with session lifetime, you never came up with any evidence.
> I could post them somewhere public and unexpected and wait
> for you to find them, but that's just rude.
Thats much better then making public statements and not tellign anybody
about it, especially not me.
> Likewise, posting long, limited-interest e-mail to a public
> distribution list is a violation of common etiquette. To those who
> are still reading, I'm sorry.
Discussing various event loops for perl is certainly within the charter of
this mailing list.
Also note that you started it - I backed up all my claims with evidence
(even if it is wrong, one can at least verify my claims).
All you did is make broad statements such as "your module has a broken
design" without ever explaining how to work around the problems I
documented that caused this allegedly "broken design".
> I kind of thought those points would be obvious.
It is possible that everything is obvious to you, but if you make broad
statements like the above you *need to back them up with evidence*.
> If you still insist on doing this publicly, please indicate your
> intent by posting your documentation for AnyEvent::Impl::POE to the
> mailing list (new thread, please).
The docoumentation always was publicly available from the AnyEvent site, also
where the benchmakr results have bene published.
Anyevent 3.3 has now been released with the POE module, though, so it should
not be a problem to find it anymore, it is on CPAN.
> OMG, we agree on something! The end times are here:
sorry?
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
