On Wed, Feb 11, 2004 at 09:54:24AM -0800, Scott wrote:I was just trying to pry better examples out of them than "This is how I wrote my program", something more along the lines of "This is how I HAD to write my program". Fortunately, Jonathan and I came up with some this morning.
Yes but this still isn't an arguement for inter-session calling, and in addition, it also not an arguement against POE::Session->call(). Just because you /can/ make everything an event, doesn't neccesarily mean it should be given or even encouraged that you should make things which rely on a synchronous state and then shoe-horn them into an asynchronous framework.Not everything needs to be an event, or so Rocco once told me.True, but POE is nice because you /can/ make everything an event, if you so desire.
The other side of this coin: Just because synchrony is bad doesn't mean it should be impossible. Languages that make bad things impossible are not much fun. Consider Pascal. And POE should be fun.
Further, as Jonathan, Nick, and Andrew have said, the badness of the
feature doesn't eliminate its utility. And the feature seems very
useful, and very well-used.
When speaking to Jonathan in response to his dns component arguement, I provided several examples where bypassing the queue can be preferrable in an inter-session call. Such as a time critical component, for intrusion or error detection. Bypassing the FIFO to prevent either further error or send notifications before anything else at all happens. Or, for another instance, halt the application before some thing VERY bad takes place...
Another good example is user interface coding. Where, at times, our load may be quiet high but we still want to give some component complete and TOTAL priority. Our user interface controlling session may need to call its requests to the component, and vice versa, in order to stop processing some large request from allowing us to stop the processing in a timely and responsive matter. This is the type of example where speed is not always in processing.
Speed is not always in CPU ticks, this I realize. Which is why I would like to propose rather than completing the RFC for Revising call, either adding yield and invoke to the sessions (Which both get the benefit of some sort of optimization, unfortunately the latter more than the prior) or simply re-optimizing call(). A short-hand form of the Kernel's call() method would be nice, anyway, in light of the Kernel's yield() method. I here actually will agree with Matt that yield() on the session object (Though I would think it would be better named yield() than post()) would match nicely an invoke() method.
As much as inter-session call gums up the current and future works, IMe too, see above reasons.
think it should stay.
Well, while the semantics of the method may not, the error checking of it does. That is, my implementation of this method has error checking to ensure you do not call Session->call() on an object that is not the currently active session. That solves that problem. Fact being, if we let them call it on an inactive session, we are going to then end up with the same problems that Kernel->call() has. If we simply assume they aren't, we're going to really end up with a headache....ah, but, if we just error when they do, they cannot...atleast not without extra work and no real gain.1. Deprecating it will be a long, drawn-out ordeal. At least a year in the making. Such a fundamental deprecation would severly delay the 1.00 release proposed in a recent article on this very list.
2. POE::Component::IKC---and every other inter-process messaging service---is not required to support inter-process call() even if POE does. Therefore, call() across a wire is a moot issue.
3. When POE acquires thread support, we might be able to run an inter- process messaging service in a separate thread. If we remove inter- session call, we'll only need to add it back later if we want to support synchronous RMI.
4. The Session->call() syntax, whether it's call() or invoke() or do()
or something else, does not prohibit inter-session call() anyway. It
does, however, imply that inter-process call() is not available, since
you can't refer to the remote session by a registered name. That seems
more limiting than the current scheme.
One is to simply add Session->invoke() and Session->yield(), and call it a day. Another is to cat /dev/null > the_patch_set, and we probably have a few more which have not come up yet. :)My previous questions stand; there seem to be design options where performance is improved without compromising POE's flexibility.
- Scott
