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/9887bdc8-a327-4224-a0ad-b0992db50e9dn%40googlegroups.com.
