@jcolp I checked the source code, and I think now I understand better the problem.
When a channel enter a stasis application, a new thread is spawned and the function
stasis_app_exec executed (file
res_stasis.c). The function enter in a while loop that performs a
ast_waitfor(channel, MAX_WAIT_MS) call that waits for events with a timeout of
Before a "channel/answer" request, the control flow is blocked on the
ast_waitfor for 200ms, then handles the requests inside
control_dispatch_all, then waits again on the
ast_waitfor and so on... I see that the while loop repeats exactly every 200ms. So, when a "channel/answer" request arrives,
ast_waitfor doesn't wake up immediately (!) but waits for the 200ms timeout. When
ast_waitfor exits for timeout, finally the channel performs the answer (WCET for the answer: 200ms).
After answering the channel, I see that the while cycle enter every 20ms, because
ast_waitfor now exits after only 20ms (and not 200ms as before). So, next requests are more responsive (WCET for following requests: 20ms).
So, it seems to me that:
ast_waitfor function doesn't work as expected (it doesn't wake up on http requests, but always wait the timeout expiration) OR
- http requests don't wake up
ast_waitfor by design (but then, what are the events it's waiting for?).
In the first case, it's a bug. In the second, it's a big performance flaw. Could you please help me understand what's the case?
Thanks a lot.