Hi again,
We're still working on the Socket class implementation and have found
one more problem. We are implementing our task as a non-periodic
activity with active polling.
The problem we're facing is as follows. When the socket created is a
stream socket, we check if the network peer is disconnected, looking
at the return value of recv function at each updateHook call. In case
it returns 0, meaning the network peer has disconnected, we'd like to
change the task state to stopped.
We've tried to call stop() from inside the updateHook function, but it
seems that it cannot take effect until updateHook is exited, which
will never happen since it is waiting for stop() function to return
(this is our guess, the fact is that we've checked that stop() blocks,
and this is how we interpret what's happening).
We've also tried using events but in this case, the event handler also
blocks when calling stop(), and updateHook blocks when launching the
event (aren't events supposed to be asynchronous?).
Which would be the best way to solve this?
Greetings,
Miguel.
stopping a task from updateHook
El 13/05/2008, a las 13:16, Miguel Prada Sarasola escribió:
> Hi again,
>
> We're still working on the Socket class implementation and have
> found one more problem. We are implementing our task as a non-
> periodic activity with active polling.
>
> The problem we're facing is as follows. When the socket created is a
> stream socket, we check if the network peer is disconnected, looking
> at the return value of recv function at each updateHook call. In
> case it returns 0, meaning the network peer has disconnected, we'd
> like to change the task state to stopped.
>
> We've tried to call stop() from inside the updateHook function, but
> it seems that it cannot take effect until updateHook is exited,
> which will never happen since it is waiting for stop() function to
> return (this is our guess, the fact is that we've checked that
> stop() blocks, and this is how we interpret what's happening).
>
> We've also tried using events but in this case, the event handler
> also blocks when calling stop(), and updateHook blocks when
> launching the event (aren't events supposed to be asynchronous?).
>
> Which would be the best way to solve this?
>
Hi Peter,
Yesterday you told this to Leo:
Message from Peter Soetens at 17:18:39
He can try attaching an asynchronous event.... by default events are
synchronous, he needs to add the parameter this->engine()->events() at
the
end of the connect() or setup() function he's using...
We've managed to make the event asynchronous, and now the event is
sent without problems. The issue with calling stop from a event
handler that's a member of the class itself is still there, however.
We'll build a supervising task to handle the event and I hope this
solves the problem.
Greetings,
Miguel.
stopping a task from updateHook
On Wednesday 14 May 2008 12:17:29 Miguel Prada Sarasola wrote:
> El 13/05/2008, a las 13:16, Miguel Prada Sarasola escribió:
> > Hi again,
> >
> > We're still working on the Socket class implementation and have
> > found one more problem. We are implementing our task as a non-
> > periodic activity with active polling.
> >
> > The problem we're facing is as follows. When the socket created is a
> > stream socket, we check if the network peer is disconnected, looking
> > at the return value of recv function at each updateHook call. In
> > case it returns 0, meaning the network peer has disconnected, we'd
> > like to change the task state to stopped.
> >
> > We've tried to call stop() from inside the updateHook function, but
> > it seems that it cannot take effect until updateHook is exited,
> > which will never happen since it is waiting for stop() function to
> > return (this is our guess, the fact is that we've checked that
> > stop() blocks, and this is how we interpret what's happening).
> >
> > We've also tried using events but in this case, the event handler
> > also blocks when calling stop(), and updateHook blocks when
> > launching the event (aren't events supposed to be asynchronous?).
> >
> > Which would be the best way to solve this?
>
> Hi Peter,
>
> Yesterday you told this to Leo:
>
> Message from Peter Soetens at 17:18:39
> He can try attaching an asynchronous event.... by default events are
> synchronous, he needs to add the parameter this->engine()->events() at
> the
> end of the connect() or setup() function he's using...
Ok. This was wrong advice.
>
> We've managed to make the event asynchronous, and now the event is
> sent without problems. The issue with calling stop from a event
> handler that's a member of the class itself is still there, however.
> We'll build a supervising task to handle the event and I hope this
> solves the problem.
It's a bug. not being able to call stop() from your own thread is clearly a
bug. Using another thread (supervisor) will work. We should report this in
Bugzilla.
Peter