On Friday 14 November 2008 15:42:15 Vandenbroucke Sander wrote:
> > -----Original Message-----
> >
> > Nasty. That check shouldn't be there for the reasons you list. It was
> > meant to
> > prevent infinite recursion when a handler function would emit the
>
> event
>
> > again.
> > Bad luck in my opinion. We don't prevent recursion in other places, so
>
> why
>
> > would we here...
> >
> > We need to define a unit test where two or more threads emit an event
>
> and
>
> > check
> > that all the emits resulted in calling the callback.
>
> I can leave this check out?

It looks like you can (the callback lock-free list is thread-safe). But we
need to unit test to be sure.

Peter

Hi, I took the following code out of signal_template.hpp

R emit(OROCOS_SIGNATURE_PARMS)
{
#ifdef ORO_SIGNAL_USE_LIST_LOCK_FREE
if (this->emitting)
return detail::NA::na(); // avoid uglyness : Handlers calling
emit.
this->emitting = true;

// this code did initially not work under gcc 4.0/ubuntu breezy.
// connection_t::get() const becomes an undefined symbol.
// works under gcc 3.4
mconnections.apply( boost::lambda::bind(&connection_impl::emit,
boost::lambda::bind(
&applyEmit, boost::lambda::_1) // works for any compiler
//not in gcc 4.0.2:
boost::lambda::ll_static_cast(boost::lambda::bind(&con
nection_t::get, boost::lambda::_1))
#if OROCOS_SIGNATURE_NUM_ARGS != 0
,OROCOS_SIGNATURE_ARGS
#endif
) );
this->emitting = false;
#else
OS::MutexLock lock(m);
if (this->emitting)
return detail::NA::na(); // avoid uglyness : Handlers calling
emit.
this->emitting = true;
iterator it = mconnections.begin();
const_iterator end = mconnections.end();
for (; it != end; ++it ) {
connection_impl* ci = static_cast( it->get()
);
if (ci)
ci->emit(OROCOS_SIGNATURE_ARGS); // this if... race is
guarded by the mutex.
}
this->emitting = false;
this->cleanup();
#endif
return detail::NA::na();
}

Notice the
if (this->emitting)
return detail::NA::na(); // avoid uglyness : Handlers calling
statements witch causes trouble for me.

I have a situation where two threads call the same event, one sometimes
preempting the other resulting in 'missed' events due to this if()
statement. I wonder what the OROCOS point of view is on this mather? I
mean: is it advised to call one event from more than one thread? Or
should I look for an other way to solve this?

Kind regards.
Sander.

On Monday 14 May 2007 11:50:06 Vandenbroucke Sander wrote:
> Hi,
>
> I'm having problems with making the RTT::Event class send/receive
> commands over CAN.
> I have a EventProxy derived from the signal template
> implementing a RTT::LocalCommand with a overridden operator()(). In this
> operator I do:
>
> void CLocalEventProxy::operator()()
> {
> if(m_El)
> m_El->sendEvent(m_Id); //--> send a CAN message.
> this->emit();
> }

Interesting, using a command for emiting events.

>
> Where I receive the CAN message I just call emit() thus preventing an
> other CAN message being sent.
>
> Using this construction I can fire an event over the CAN network from a
> proxy to a server. It is the other way around I can't get away with.
>
> For Commands and DataPorts I change the implementation to a
> server-implementation if they are in the interface of the TaskContex's I
> want to export over CAN (using commands() and ports()). I was hoping I
> could do the same thing with Events. The problem is that the objects
> stored in the EventService, returned by events(), are already
> implementations. So I can't just change them can I? Or are the shared
> pointers smart enough to handle this?

I'll have to look into this. You can use Event::operator= to assign a new
implementation before adding the event to the EventService (before
events()->addEvent( &e ) or after you get the Event (this completely removes
the old function then) and there is also an Event constructor which accepts
the implementation. You may change the implementation of an Event (about) at
any time. I don't fully understand your case yet though.

Do you need both local and remote delivery implementations of the Event ?

Peter