| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
|
It’s already there as well. The calls to checkAsyncProcessHandler()
in SipStack.cxx cause a select interrupt to happen when the TU queus an item to
the SipStack fifo. You must pass the SelectInterruptor into the
stack as an AsyncProcessHandler when you create it. Note: InterruptableStackThread
is used in the recon project. Documentation on the wiki would be a good
to add. : ) Scott From:
resiprocate-users-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-users-bounces@xxxxxxxxxxxxxxx] On Behalf Of Byron
Campen Huh,
guess I never looked at that code. So, maybe what we should think about doing
is putting the necessary wiring in place to cause an interrupt to happen if an
InterruptableStackThread is being used. Best regards, Byron Campen
This is already implemented in resiprocate. : ) See
the SelectInterruptor and InterruptableStackThread classes. Scott On Wed, May 6, 2009 at 4:43 PM, Vasanthi Ramasamy <Vasanthi.Ramasamy@xxxxxxxxxxxxxxxx>
wrote: “A while back, I
noticed a slight problem in the way the stack's process loop is constructed.
The issue is that we can get in a situation where we are blocking on a select
call (in the transport code) when there is work to be done in the transaction
layer. Basically, let's say we get down into the select call; we're waiting for
an fd to become ready. Then, the TU sends a request down to the stack. This
does not interrupt the select call; we sit there waiting for an fd to become
ready for 25ms, time out, and then notice the new work that the TU kicked down
to us. We could solve this by using the "self-pipe" trick; where we
have an anonymous pipe that we write a single byte to whenever stuff gets put
in the state machine fifo, and we select on this pipe's fd along with the
transport fds.”
Thanks, Vasanthi
_______________________________________________ |