Subscriber-like operations only works when compiled with `NDEBUG`

[yunjing]

I am trying to build a pipeline that behaves similarly as Subscriber. I could not use broadcast pipeline directly because broadcasting is not the desired default behavior. So the basic operations look like follows: Client A connects and subscribe so I save Context A Client B connects and issued a request that A is interested in, so I write data to Context A.

Interestingly, this code works as expected only when compiled with NDEBUG flag on. I otherwise get a DCHECK failure that can be traced back to folly: https://github.com/facebook/folly/blob/2c8de414e51305fa00ef6efdab69de0fbda7aff1/folly/io/async/EventBase.cpp#L494

While the check appears in the folly code, I am wondering what is the right approach of mimicking the behavior of wangle's broadcast pipeline.

[viswanathgs]

Client A and Client B need not end up being processed by the same thread. What seems to be happening is that you are writing Context A from thread 1 (which received Client A's request) to thread 2 (which received Client B's request).

If you know which thread has Context A and you have access to the EventBase of that thread, you can do runInEventBaseThread (https://github.com/facebook/folly/blob/2c8de414e51305fa00ef6efdab69de0fbda7aff1/folly/io/async/EventBase.cpp#L545) to schedule writing on that thread.

Another approach is to use AcceptRoutingHandler is to make sure all clients that want to read/write to the shared context end up in the same worker thread (https://github.com/facebook/wangle/blob/master/wangle/bootstrap/AcceptRoutingHandler.h). Take a look at how this could be done in this example: https://github.com/facebook/wangle/blob/master/wangle/example/accept_steering/accept_steering_server.cpp.

I'd be able to help out more if you paste code snippets.

[yunjing]

Thanks for the quick reply. We made it work by using runInEventBaseThread.