LP #1222709: Bug 951588 fix needs revert and re-fixing
General
Escalation
General
Escalation
Description
**Reported in Launchpad by Laurynas Biveinis last update 21-07-2015 12:14:48
Bug 951588 was about the fact that calling handler ::info from another thread is inherently unsafe because it overwrites the handler state, causing troubles for the handler-owning thread. The fix was to clone handler first, and then run ::info on the cloned handler.
This fix is very fragile: see bug 1113388, bug 1193264, bug 1193308, bug 1206486, bug 1205200, bug 1204859, bug 1206020, and probably others. handler::clone() was not designed for such use.
A better is fix is needed. One option would be to implement new small info-like method for handler that returns the already-available information from the handler without doing a full clone nor info.
Un-duplicated the individual I_S.GLOBAL_TEMPORARY_TABLES bugs, and will fix the analysed ones without moving away from the use of handler::clone. That should allow GLOBAL_TEMPORARY_TABLES to become subject to QA again, and then the remaining i-s-temp-tables bugs can be fixed as they are analyzed or as the testcases are produced by QA.
**Reported in Launchpad by Laurynas Biveinis last update 21-07-2015 12:14:48
Bug 951588 was about the fact that calling handler ::info from another thread is inherently unsafe because it overwrites the handler state, causing troubles for the handler-owning thread. The fix was to clone handler first, and then run ::info on the cloned handler.
This fix is very fragile: see bug 1113388, bug 1193264, bug 1193308, bug 1206486, bug 1205200, bug 1204859, bug 1206020, and probably others. handler::clone() was not designed for such use.
A better is fix is needed. One option would be to implement new small info-like method for handler that returns the already-available information from the handler without doing a full clone nor info.