You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While looking through the examples I cannot find how to not immediately send back a reply, but instead to have some form of handle stored so that it will be returned later, after the background task returned a reply. This would block the connection on HTTP.
The text was updated successfully, but these errors were encountered:
Yes, as you mentioned, this part has to be handled in user code, you could implement a set of queuing buffer mapped to each connection. And this delayed response better to be handled in separate threads, not to block the callback since the callback is single-threaded model anything blocking the callback will block the whole process.
I understand how to not block the call, but what kind of value do I return to indicate "I'm processing this connection on a separate thread, please continue processing other connections but don't do anything to this connection until I tell you I'm done" ?
I guess you need to save the underlying *conn object in your threads and send data using the conn from the threads. I think you can also use ad_conn_set_userdata() call to store the status information if needed.
While looking through the examples I cannot find how to not immediately send back a reply, but instead to have some form of handle stored so that it will be returned later, after the background task returned a reply. This would block the connection on HTTP.
The text was updated successfully, but these errors were encountered: