In that approach you would need to extend from a base class:
class MyBaseMethod {
virtual void Proceed() = 0;
};
class MyFirstMethod : MyBaseMethod {
void Proceed() overrride {
// do the work of first method.
}
};
class MySecondMethod : MySecondMethod {
void Proceed() overrride {
// do the work of second method.
}
};
Then case to BaseMethod:
bool ok;
while (true) {
if (!m_cq->Next(&tag, &ok)) break;
MOOSE_ASSERT(ok);
static_cast<MyBaseMethod*>(tag)->proceed();
}
On Fri, Oct 12, 2018 at 12:06 PM Stephan Menzel <[email protected]>
wrote:
> Hi Christian,
>
> thanks for your response.
>
> Am Freitag, 12. Oktober 2018 11:53:21 UTC+2 schrieb Christian Rivasseau:
>>
>>
>> 1: It is indeed very much possible to have multiple methods, you just
>> need to arrange for your own CallData object that will
>> handle different methods. Depending on your style you could:
>> - Have a enum in the CallData constructor that describe which method is
>> handled, and switch on that.
>> - Use inheritance (have a CallData subclass for each GRPC method).
>> - Takes functors that perform the work as arguments.
>>
>
> OK, this is pretty much what I did already. My problem is, at which point
> do I know which method is called? Let me use that modified HandleRpcs()
> example to explain:
>
> Suppose I went for your second choice and have a type per call.
>
> void MyServerImpl::HandleRpcs() {
>
> // Spawn a new CallData instance for each method. Is that right?
> new MyFirstMethod(&m_service_instance, m_cq.get());
> new MySecondMethod(&m_service_instance, m_cq.get());
>
> void* tag; // uniquely identifies a request.
>
> bool ok;
> while (true) {
> // Block waiting to read the next event from the completion queue. The
> // event is uniquely identified by its tag, which in this case is the
> // memory address of a CallData instance.
> // The return value of Next should always be checked. This return value
> // tells us whether there is any kind of event or cq_ is shutting down.
> if (!m_cq->Next(&tag, &ok)) break;
>
> MOOSE_ASSERT(ok);
>
> // This here:
> // How do I know which call it is? To which type do I cast this tag void
> ptr? The first or the second?
>
> static_cast<MyFirstMethod *>(tag)->proceed();
> }
> }
>
>
>
>> Then when your server starts you will need to instantiate the first
>> CallData object for each method.
>>
>> 2: The example is indeed synchronous in its process phase. In real life
>> you will be offloading work to some thread pool,
>> or calling async services of your own, and then you can call
>> responder_->Finish() once that is done.
>>
>
> OK, so my separate io_context approach will provide that just fine.
>
> Thanks!
>
> Stephan
>
> --
> You received this message because you are subscribed to the Google Groups "
> grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/89d54d5c-af86-4a17-8e13-3446bc286aa0%40googlegroups.com
> <https://groups.google.com/d/msgid/grpc-io/89d54d5c-af86-4a17-8e13-3446bc286aa0%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Christian Rivasseau
Co-founder and CTO @ Lefty <http://www.lefty.io>
+33 6 67 35 26 74
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/CAJ6g4%3DaHN7LxjMG2MCiYrgXwY3kTwSfiLc6GG7tPfcjto2pNGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
