Dmytro Mishchenko wrote:
Hello,
Here is a problem with IAX and probably other kind of channels.
IAX2 channel function socket_read() process all kind of IAX frames.
Frames of type: IAX_COMMAND_REGREQ, IAX_COMMAND_AUTHREQ, IAX_COMMAND_AUTHREP etc. may take some significant time for processing. E.g. in the case when realtime engine will try to get data from DB. If this time is even half of a second its enough to interrupt ALL currently running calls. All audio streams delayed until one frame being processed. It makes audio choppy.
I'm thinking that such kind of work as finding user should be scheduled and executed by other thread. Does it make sense? Or may be some other solution can be used?
I've talked about this with people in chat before, and yes, you're right.
This wasn't really as big of an issue before RealTime stuff was added, because before then, everything was CPU-bound, and there weren't any(?) cases where these actions would block.
Now, though, there are.
So, there's lots of solutions to the problem, and I would probably go with this:
Have a pool of "worker" threads, and a "work queue". When socket_read reads and parses frames, if there's a possible blocking operation involved (like ARA), it puts the frame into the work queue, which these worker threads are waiting on (or servicing). It would seem that other than some reorganizing of socket_read (probably to break it up into smaller functions), this could be done without having to do major surgery.
I'm not sure myself which types of frames can lead to blocking like this, but it certainly would only be a tiny minority of the frames that are being processed.
There is a thing to watch here, you might need to ack the command frame before you actually act on it, then
send an explicit response eg REGREJ or REGACK. Eitherway the IAX sequence numbering gets a
bit more complex to implement than in the single thread version.
Tim.
