[Wt-interest] Order of execution of signals

[Aarón Bueno Villares]

I have a WFileUpload widget whose uploaded() signal is connected to two
different functions, one creating a database object, and another one
showing information about the newly created db object.

It's obvious that the first function must be invoke before the second one,
so, I connected both functions to the signal in that order. But it seems
that the functions are being called in inverse order of connection (which
contradicts the behaviour of boost::signals2 as far as I know), and that
caused me some headeaches and segmentation faults.

So, the question is: in which order are the connected functions invoked
when calling `emit()`? In the reverse order of connection, or that depends
on the context or on some Javascript logic?

Best regards,
Peregring-lk

[Koen Deforche]

Hey Aaron,

Post by Aarón Bueno Villares
I have a WFileUpload widget whose uploaded() signal is connected to two
different functions, one creating a database object, and another one
showing information about the newly created db object.
It's obvious that the first function must be invoke before the second one,
so, I connected both functions to the signal in that order. But it seems
that the functions are being called in inverse order of connection (which
contradicts the behaviour of boost::signals2 as far as I know), and that
caused me some headeaches and segmentation faults.
So, the question is: in which order are the connected functions invoked
when calling `emit()`? In the reverse order of connection, or that depends
on the context or on some Javascript logic?

The order is undefined and you shouldn't rely on it. In the above scenario,
you should try to reorganize your code so that the second function is not
connected to the WFileUpload uplodaed() widget, but to a signal emitted in
response to creating a new database object.

Koen

[Aarón Bueno Villares]

Thank you, pretty clear.

Post by Koen Deforche
Hey Aaron,

Post by Aarón Bueno Villares
I have a WFileUpload widget whose uploaded() signal is connected to two
different functions, one creating a database object, and another one
showing information about the newly created db object.
It's obvious that the first function must be invoke before the second
one, so, I connected both functions to the signal in that order. But it
seems that the functions are being called in inverse order of connection
(which contradicts the behaviour of boost::signals2 as far as I know), and
that caused me some headeaches and segmentation faults.
So, the question is: in which order are the connected functions invoked
when calling `emit()`? In the reverse order of connection, or that depends
on the context or on some Javascript logic?

The order is undefined and you shouldn't rely on it. In the above
scenario, you should try to reorganize your code so that the second
function is not connected to the WFileUpload uplodaed() widget, but to a
signal emitted in response to creating a new database object.
Koen
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
witty-interest mailing list
https://lists.sourceforge.net/lists/listinfo/witty-interest

[Aarón Bueno Villares]

No so clear haha. Has every kind of event "undefined" order? or only when
connecting to "javascript" signals? For example, if I connect two or more
slots to the "closeEditor" signal of an ItemDelegate, is that order also
undefined? Because the "closeEditor" signal doesn't depend directly on
javascript events, rather, its triggered "manually" by the ItemDelegate
class, and in that case, in my understanding, the order is the one defined
by the boost::signals2 library (which is the order of connections).

Post by Aarón Bueno Villares
Thank you, pretty clear.

Post by Koen Deforche
Hey Aaron,

Post by Aarón Bueno Villares
I have a WFileUpload widget whose uploaded() signal is connected to two
different functions, one creating a database object, and another one
showing information about the newly created db object.
It's obvious that the first function must be invoke before the second
one, so, I connected both functions to the signal in that order. But it
seems that the functions are being called in inverse order of connection
(which contradicts the behaviour of boost::signals2 as far as I know), and
that caused me some headeaches and segmentation faults.
So, the question is: in which order are the connected functions invoked
when calling `emit()`? In the reverse order of connection, or that depends
on the context or on some Javascript logic?

The order is undefined and you shouldn't rely on it. In the above
scenario, you should try to reorganize your code so that the second
function is not connected to the WFileUpload uplodaed() widget, but to a
signal emitted in response to creating a new database object.
Koen
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
witty-interest mailing list
https://lists.sourceforge.net/lists/listinfo/witty-interest

[Koen Deforche]

Hey Aaron,

"manually" by the ItemDelegate class, and in that case, in my

understanding, the order is the one defined by the boost::signals2 library
(which is the order of connections).

In both cases there is an order assumed internally, but what we mean to say
is that it is bad practice to rely on this. A dependency as subtle as this
is better visible in your source code somehow.

And we indeed do not really promise to maintain the current order (for
example when moving to a new signals implementation in wt4).

Regards,
Koen