servermain.cpp have another problem, when AsyncNotifyWhenDone called, still need call IsCancelled() to check whether is cancelled, servermain.cpp just think it's cancelled
在2022年4月10日星期日 UTC+8 05:46:37<YZ Xie> 写道： > servermain.cpp has race conditon may cause null point core, here is occur > steps: 1. in bidirection rpc when finish execute asyncOpFinished in onRead, > at this moment, ok was true, before > execute asyncOpStarted, AsyncNotifyWhenDone called, mAsyncOpCounter will be > 0 at this moment, so this rpc deleted by done function, ok still be true, > so processIncomingRequest will be called, but this was deleted, core > occured. but I'm not sure was I'm right, I think I'm right, so I > think asyncOpFinished and asyncOpStarted need lock > > 在2017年7月25日星期二 UTC+8 02:19:57<[email protected]> 写道： > >> Hi, >> >> The tagInfo/callData can be whatever you want. In the example I attached, >> the 4 different rpc implementations encapsulate all the state machinery >> that async gRPC needs in a manner that is transparent to rest of the >> application code. The tagInfo just 'ends up' at the right state. >> >> The idea is to provide meaningful implementation of the 'RpcHandlers' >> when your application instantiates the rpc. That implementation can be per >> rpc (as I have done in the sample - for example, each rpc gets it's own >> processor implementation) or can be per service etc. It just depends on how >> your application is set up. My application is adding gRPC support in >> addition to our current rpc framework so what I do is simply figure out the >> existing handler in the implementation of those methods and route the rpc >> appropriately (This is not how example I attached is set up btw). >> >> For threading, yes, I have a dedicated thread for processing completion >> queue. It's not a busy loop though - the completion queue internally yields. >> >> I have re-attached a new sample that is simplified than the one I >> attached earlier. This is pretty much a cleaned up version of what I use in >> my app today. This one adds the error handling capabilities and makes >> sending rpc responses and their lifetime management easier. >> >> HTH. >> >> >> >> On Friday, July 21, 2017 at 8:42:43 AM UTC-7, [email protected] wrote: >>> >>> Hi Arpit, I had a couple follow-up questions: >>> >>> I'm looking at your code and mine, and how multiple services might be >>> supported. It seems like the "Request*" function is the one that blocks on >>> a service type, and you essentially need to have create a different >>> CallData (or TagInfo in your case) for every type of Service. Is that >>> right? I only want to have a single thread handling the requests coming in, >>> so I believe I should make a new CallData/TagInfo for every type of Service >>> I have at the start, then sit in a busy loop on my only thread calling Next >>> on the completion queue. It seems like the cleanest way to do that is >>> something similar to what you have, where every Service type implements its >>> own CallData/TagInfo class to do the processing it needs to do for each >>> function. Does all this sound okay? >>> >>> >>> On Thursday, July 20, 2017 at 1:43:13 PM UTC-7, Arpit Baldeva wrote: >>>> >>>> You can add as many services as you like to a single server (using >>>> RegisterService call). >>>> >>>> Check out the following post for a better (but complicated sample) >>>> https://groups.google.com/forum/#!topic/grpc-io/DuBDpK96B14 . It does >>>> not show multiple services but that part is not complicated. >>>> >>>> On Wednesday, July 19, 2017 at 8:32:35 PM UTC-7, [email protected] >>>> wrote: >>>>> >>>>> Hi, I'm trying to understand how to convert an application using >>>>> synchronous RPC to asynchronous. My old method for synchronous >>>>> communication was calling RegisterService on all my services, then >>>>> calling >>>>> Wait() on the server after it was created. The gRPC library would decide >>>>> which Service function to call from that point. >>>>> >>>>> When I look at the async C++ example, the beginning looks very similar >>>>> where the services are added, and BuildAndStart is called. But instead of >>>>> calling Wait(). HandleRpcs is called as the busy loop. However, it looks >>>>> like HandleRpcs is only handling a single type of service. I don't see >>>>> any >>>>> examples of adding multiple services anywhere, so I'm not sure how that's >>>>> handled. Does it imply that I would have to make essentially a separate >>>>> ServerImpl class for every type of service? >>>>> >>>> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/1be75908-fc17-46f5-80c6-4f925991f12an%40googlegroups.com.
