I believe there was a proposal internally that if the caller passes None for
the callback, the RPC implementation should block until completion and then
return the result.  Does that seem like what you want?

On Wed, Jan 7, 2009 at 6:23 PM, Alan Kligman <alan.klig...@gmail.com> wrote:

>
> I poked around a bit and the code above isn't correct (for a couple of
> reasons). But the question remains: should stubs be generated that
> return the response down the callstack instead of passing it through a
> callback function?
>
> On Jan 7, 5:59 pm, Alan Kligman <alan.klig...@gmail.com> wrote:
> > Does it make sense to change
> >
> >     stub.rpc_channel.CallMethod(
> >         method_descriptor, rpc_controller, request,
> >         method_descriptor.output_type._concrete_class, callback)
> >
> > to
> >
> >     return stub.rpc_channel.CallMethod(
> >         method_descriptor, rpc_controller, request,
> >         method_descriptor.output_type._concrete_class, callback=lambda
> > x:None)
> > in python/google/protobuf/service_reflection.py?
> >
> > If, for example, I'm running in a single thread and my underlying
> > channel is blocking, it's strange to pass a callback in when control
> > would normally return to the calling method after CallMethod has
> > completed synchronously.
> >
> > Thoughts?
> >
> > a
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to