On 2/19/07, Timmo Stange
Gottlob Frege wrote:
This is starting to sound promising. I could also imagine that disconnect returns some kind of event that you can choose to wait on or not.
[...]
ie, the signal code, instead of calling the disconnect callback, triggers the event.
Not as generic as a callback, but maybe more efficient?
Leaving aside the lack of a simple event primitive in Boost.Threads, we could easily provide a predefined callback functor in Signals that implements this, but I have the feeling we're running in circles here, because that is exactly what we don't want the client code to do: If two slots use that approach with disconnect, the outcome may be a deadlock - not on the slot mutexes this time, but on the "slot return events" ;).
I understand that, but I guess I'm still clinging to the idea that for most uses, you do want to wait, and won't be in a situation where you could deadlock. We are just moving along the line of how hard/easy it is to use and how hard/easy it is to deadlock. The biggest step is just moving the locking out of the signal and over to the user code so that the user has the option to handle things how they want. From there, it is what do you want to make easy/hard, encourage/discourage. Tony P.S. the 'event' primitive would be pretty easy to implement. But yeah, it doesn't really exist currently.