tim panton wrote:
On 21 Dec 2005, at 15:39, Steve Kann wrote:
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.
Locking in general gets more complex!
I'm not sure how it's done now, but you can handle delayed acks just
like retransmissions: you can immediately schedule a delayed ack when
you get something, and then, whenever you send a full frame, check to
see if there's a scheduled ack, and if there is, piggyback the sequence
number change with your full frame, and then cancel the ack.
-SteveK
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
