Maybe this could helps better, since this wiki talks about
non-blocking I/O operation

http://developer.symbian.org/wiki/index.php/Symbian_OS_Communications_Programming/3._An_Introduction_to_ESOCK

On Wed, Dec 9, 2009 at 4:55 AM, nir elkayam nir.elkayam@gmail.com wrote:

implementing ASync operation is a big change. the suggested way is half way
that might do the work in correcting the problem mention at the end of:

http://trac.pjsip.org/repos/wiki/Symbian_AP_Reconnection

nir

On Tue, Dec 8, 2009 at 11:32 PM, atik atik.khan@gmail.com wrote:

--
ניר אלקיים
טל: 050-3930056
nir.elkayam@gmail.com

Guys,

I suppose I have faced with ViewSrv 11 crash due to this blocking stuff.

ViewSrv 11:
The most common panic. A view has taken too long to complete its
implementation of ViewActivatedL() and must, therefore, be panicked to stop
it from blocking the entire OS.

Do you observe such crash? Any idea how to resolve?

Best Regards
*Vasyl

2009/12/9 nir elkayam nir.elkayam@gmail.com

I haven't face this my self. validate that there is no "pjsip" calls done
during the changing view code - the ui should be able to complete the view
replacement without waiting to pjsip.
I will implement the (my) suggested to syncronise, but thats also has its
downsides.

benny, nanang, can u suggest a way to implement the PENDING case on the
ioqueue and maybe we'll do it ourself?

nir

On Thu, Dec 10, 2009 at 12:45 AM, Vasyl Strutynskyy <
vasyl.strutynskyy@gmail.com> wrote:

--
ניר אלקיים
טל: 050-3930056
nir.elkayam@gmail.com

On Tue, Dec 8, 2009 at 8:55 PM, nir elkayam nir.elkayam@gmail.com wrote:

So the trick allows program execution to block at
CActiveScheduler::Start(), similar to User::WaitForRequest(), but
unlike User::WaitForRequest(), it allows other pending requests to
complete while we're waiting for the blocking request to complete? If
this is correct then that sounds like a good trick, thanks for
sharing.

Although I'm concerned, that this could cause other active objects to
be called in an unexpected state. For example, while waiting for
Send() to complete, a timer elapsed which destroys a transaction, and
when Send() finally returns, the transaction is no longer there. What
do you think?

Cheers
Benny

hi benny,

I see what u say but this issue will also raise with using regular async
events.
there should be ability to Cancel the request and this can be implemented
too.

however, I am not sure this will happen as once the send is schedule it
should be completed with notify back to the sender.
the cancel should be done only when destroying the underline transport.

is there anyway where u implement the PENDING state on send/sendto (i mean
other os.)

nir

On Thu, Dec 10, 2009 at 7:56 AM, Benny Prijono bennylp@teluu.com wrote:

--
ניר אלקיים
טל: 050-3930056
nir.elkayam@gmail.com

On Thu, Dec 10, 2009 at 6:47 AM, nir elkayam nir.elkayam@gmail.com wrote:

The difference is, normally we would expect events to happen inside
the "poll" function, and we can be sure that things are in good state
before the events are executed.

With the CActiveScheduler::Start() approach, now events can happen
pretty much anywhere where this approach is used. Like I said, for
example a timer event may elapse while we're inside pj_sock_send(),
and this is bad.

Async I/O is always done with ioqueue.

Cheers
Benny

ok, i see what u mean.

the call to the new "WaitForEvent" should be the last code in the
pj_sock_send() and no other code exept for error handeling should be there
like i see for example:

/*

• Send data
  */
  PJ_DEF(pj_status_t) pj_sock_send(pj_sock_t sock,
  const void *buf,
  pj_ssize_t *len,
  unsigned flags)
  {
  PJ_CHECK_STACK();
  PJ_ASSERT_RETURN(sock && buf && len, PJ_EINVAL);

  // Return failure if access point is marked as down by app.
  PJ_SYMBIAN_CHECK_CONNECTION();

  CPjSocket pjSock = (CPjSocket)sock;
  RSocket &rSock = pjSock->Socket();

  // send() should only be called to connected socket
  PJ_ASSERT_RETURN(pjSock->IsConnected(), PJ_EINVALIDOP);

  TPtrC8 data((const TUint8*)buf, (TInt)*len);
  TRequestStatus reqStatus;
  TSockXfrLength sentLen;

  rSock.Send(data, flags, reqStatus, sentLen);
  User::WaitForRequest(reqStatus);

  if (reqStatus.Int()==KErrNone) {
  //*len = (TInt) sentLen.Length();
  return PJ_SUCCESS;
  } else
  return PJ_RETURN_OS_ERROR(reqStatus.Int());
  }

On Thu, Dec 10, 2009 at 9:14 AM, Benny Prijono bennylp@teluu.com wrote:

--
ניר אלקיים
טל: 050-3930056
nir.elkayam@gmail.com

sorry, my bad. i see it now.
the problem is with the function that calls pj_sock_send..

but how about implementing true async event? i think in the udp case it
should be simple:
on incomming msg to send, if it not busy, schedule it the send, and if its
busy, ignore the msg.
on TCP, some q should be added.

nir

On Thu, Dec 10, 2009 at 9:21 AM, nir elkayam nir.elkayam@gmail.com wrote:

--
ניר אלקיים
טל: 050-3930056
nir.elkayam@gmail.com