From what I understand the relationship of signals to slots is (1:N) where N is 0 to some number. So I have to have some structure in place so that I keep things safe (e.g. no race conditions or starvation) while
Since it has been advise by many people in the past that retrofitting software is troublesome and expense. I am looking at the issues of redesigning the signals library from scratch to keep the same interface. Before providing a new solution to consider I have a few questions. Is the relationship of signals to slots 1 to N where N = 0 to some value? From what I have read I believe this is true. Since signals are not copyable? N processes desiring to signal the M slots (N = 0 to some value N, M = 0 to some value M) will have to do it through the same signal object if the processes are of the same type (class has an signal object as a variable). Right? The second question comes from my initial understanding of the signals library. I was thinking about this scenario: There is a class call Cart which has a signal boost::signal<void()> in_Parking_Lot in it. Since a store will have multiple Carts for customers to use the owner has programmed his carts to signal the front desk computer when they are moved out of the store. class Cart { private: boost::signal<void()> in_Parking_Lot; public: void init (FrontDesk& fd) { in_Store = true; in_Parking_Lot.connect(fd); void process () { for (;;) { Check location (If in store set in_Store = true vice versa if not). if ( ! in_Store ) { in_Parking_Lot(); } } }; So if I have a very small shop with 50 Carts, all 50 Carts be using the same signal object to alert the front desk. If I had a big computer with 51 cpus (50 Carts and 1 FrontDesk) to run each process I have a race condition. Which process gets to alert the front desk when? maintaining throughput when the 50 processes try to send a signal at the same tiem. So given my example I was wondering what are the properties that I need to maintain? For example should each call to the signal's operator() function be blocking (each signaling process must update all the slots listening for the signal before returning) or non-blocking (some other process handles updating the slots while the signaling process returns back to work right away). The final question is that if indeed the relationship of signals to slots is 1:N then the multi-threading problems begins to surface more predominately. That is T threads, where T is a Cart object, use 1 signal to notify N slots. We have a restricted resource, the 1 signal, to update N slots at various times during the lifetime of the T threads. Is this the problem of using the signal library with multiple threads? I will leave things there for now and await your response. Stephen