Re: [Fwd: Re: Sending slots to main thread]



En/na Joaquim Duran ha escrit:
> Sorry for the delay in the answer, but yesterday I only send the answer
> message to Paul Davis. I pressed the wrong button.
> 
> Sorry.
> 
> 
> Joaquim Duran
> 
> 
> -------- Missatge original --------
> Assumpte: Re: Sending slots to main thread
> Data: Mon, 27 Aug 2007 16:27:35 +0200
> De: Joaquim Duran <joaquinduran adtelecom es>
> Respon a: joaquinduran adtelecom es
> Empresa: AD Telecom
> A: paul linuxaudiosystems com
> Referències: <46D2B629 6050003 adtelecom es>
> <1188217101 10370 32 camel localhost localdomain>
> 
> En/na Paul Davis ha escrit:
>> On Mon, 2007-08-27 at 13:31 +0200, Joaquim Duran wrote:
>>> Dear all,
>>>
>>> I've been testing the thread related objects of gtkmm. I've seen that it
>>> is possible to connect a slot to a dispatcher to send the slot to the
>>> main thread. The problem is that only one type of slot could be attached
>>> to the Dispatcher.
>>>
>>> IS there any way to send any type of slot to the main thread? The
>>> behavior should the same or very close to ThreadPool.
>> sigc::bind is your friend here. you might also find using
>> sigc::hide_return useful too.
>>
> 
> 
> Yes, I know that, but,.... in the Dispatcher you are able to connect a
> signal with parameters to it only once and that signal can be emitted as
> many times as needed (always with the same parameters values).
> 
> Meanwhile, the in the Thread pool, each time a slot is sent, different
> parameters values could be used.
> 
> Perhaps a message queue is needed to send slots with different
> parameters values to main thread, and notify to main thread using a
> signal in a Dispatcher?
> 
> Joaquim Duran
> 
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
> 
> 

Continuing with the discussion: I've downloaded the glibmm source code.
I've seen that the Thread Pool implements the SlotList, but privately.

IMO, I think that the SlotList object should be made public mainly for
two reasons:

- It could help to implement the command patern in Glibmm: an action
could be seen as a list of slots to be excecuted. Even, the object that
fills the list of slots, could be different that the object which will
execute them.

- This is pretty easy to create an object to send arbitrary slots to
main thread (like thread pool). Pseudocode:

class dispatchslots:

ListStot __list;
Dispatcher __dispt;

void push(slot)  // Executed by working thread
{
   __list.push(slot);
   __dispt.emit();
}

void run_slot()  // Exceuted by main thread (connected to dispatcher)
{
   slot = __list.top();
   __list.pop();
   slot.execute();
}



What do you think about that?

Thanks and Best Regards,
Joaquim Duran



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]