Re: [repro-users] questirons about fdset built in process loop
The transaction state timers also need cycles - so process definitely needs
to be called.
I suspect the process loop just needs to check if the fd set returned from
buildFdSet is empty, and if so, then skip the select call and just sleep for
the timeout duration of the select.
Scott
-----Original Message-----
From: repro-users-bounces@xxxxxxxxxxxxxxx
[mailto:repro-users-bounces@xxxxxxxxxxxxxxx] On Behalf Of Byron Campen
Sent: September 20, 2007 6:32 PM
To: Neal Sidhwaney
Cc: repro-users@xxxxxxxxxxxxxxxxxxxx; neal.sidhwaney@xxxxxxxxxxxx
Subject: Re: [repro-users] questirons about fdset built in process loop
The DNS resolver needs you to give it cycles through the usual
select/process loop approach. So, the assert probably needs to be changed to
cope with this condition. (Is there anything in the resip code that might do
this kind of thing that I need to go after?)
Best regards,
Byron Campen
> Hi
>
> We are registering an external transport that does not share the stack
> process & select, i.e. shareStackProcessAndSelect() returns false.
>
> It appears that the FDSET built during the application loop can be
> empty, causing the assertion in the following sample code to return
> -1:
>
> int err =
> fdset.selectMilliSeconds(resipMin((int)
> stackUac.getTimeTillNextProcessMS(),
> 50));
> assert ( err != -1 );
> stackUac.process(fdset);
>
> My question is, is the programming model provided in the sample code
> not applicable when our own custom transports handle socket behavior
> themselves(and happens to be the only transport registered)?
>
> If the assertion is not meant to be there for my scenario, do we still
> need the fdset processing for the asynchronous DNS query results?
>
> Thanks!
>
> Neal
> _______________________________________________
> repro-users mailing list
> repro-users@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/repro-users