Hello Mark, On Thu, 2002-05-23 at 02:17, Mark McLoughlin wrote: > I won't address the problem you're trying to solve, because I > haven't had much experience of it, but the way you plan to implement > the solution is just plain wrong.
It's a real shame that you didn't understand the problem before considering the efficacy of the solution I proposed. Let me re-state it more simply; we need the following: a) Stubs that during invocation will not re-enter b) Stubs that during invocation will re-enter We also would like to be able to delay server side request processing until idle, here the requirements fit closer to an extra POA policy as you suggest - but for the fact that we do not want the policy to apply to all methods ( eg. ref / unref / queryInterface ) - but to a sub-set of methods. I imagine it might be possible to do something grotesque that would lookup methods by name, and provide a custom OA ( with a big API, a secondary method lookup, or somesuch ) to achieve the latter goal - but it seems unnecessarily complicated to me. > The idea behind IDL is that you specify the details of the > interface to the service i.e. you seperate the details of the > implementation from the interface. The way in which requests are > processed is an implementation issue. Well - there is no need for the request processing data to be in the IDL per-se, I'm more interested that it's in the generated IMethod data so we can get at it quickly. If you want to be a purist, we can have a separate file ( perhaps an XML:panacea file ), that marks up the generated C -common.c source, but it's going to be a pain. At the end of the day, we need to associate processing data with each method, and it makes lots of sense (to me) to do this at compile time, rather than execution time. I will however alter the ORBit2 ABI before releasing, so that we push the index into the IMethod data into the stub invoke, so we can try and associate such things on a per client basis - but this is just futile. We need to be able to control stub invocation re-enterancy, and this is just not possible (nor desirable) to do on a per CORBA_Object handle basis [ not to mention that all the CORBA_Object handles are shared amongst clients necessarily; selecting amongst the different options on incoming object references is just impossible blah blah. ]. > Not only that, but its a detail of the POA. And the way the > POA behaviour is configured is through the use of POA policies. Think > about it - how different from the RequestProcessingPolicy, the > LifespanPolicy or the ThreadPolicy is this? So really, if you want to > make to make this behaviour configurable, you should do so by adding > another POA policy. A POA policy is not really powerful enough to do what we want to do IMHO, possibly we could make it good enough - perhaps conditional idle processing for oneway methods. But again this only solves half the problem. In conclusion - no I'm not suggesting binning CORBA, adding some #pragmas or other method annotation either in or parallel to the IDL to describe how we want the processing to occur seems not unreasonable, nor wrong to me. Furthermore, other ORBs will ignore this information, leaving us CORBA compatible on the wire, CORBA compatible at the IDL and API level - but without uncontrolled re-entrancy in our implementations. I hope this helps explain what I propose, Regards, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers