Details
-
Type:
Task
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Fix Version/s: 10.2
-
Component/s: None
-
Labels:None
Description
We want to make Items reentrant, so calculation can be distributed between different processors. This will be very useful for UNIONs, but possible use cases will not be really limited only to UNIONs.
Currently there is an obstacle to make Items reentrant:
many of them, and especially Item_func*, store various intermediate String values inside themselves, as members.
Some examples:
class Item_func_ord :public Item_int_func { String value; public: ... };
class Item_func_md5 :public Item_str_ascii_func { String tmp_value; public: ... }
class Item_func_date_format :public Item_str_func { int fixed_length; const bool is_time_format; String value; public: ... }
All these members should be removed.
The reasonably short values should be moved on stack,
e.g. using the StringBuffer<size> template.
The long values should be moved to THD, as a sort of String pool.
The method
String *Item::val_str(String *to);
should be turned to:
String *Item::val_str(String *to, String_pool *pool) const;
Or, possibly, even to:
String *Item::val_str(String_pool *pool) const;
so the final String value can also be allocated on String_pool.
String_pool can have a constructor accepting a String object:
String_pool(String *str);
to keep polymorphism, so the old code still works:
String buffer, *tmp= item->val_str(&buffer);
The above call will be convenient for the cases when we don't need to reuse the memory allocated by intermediate values during Item->val_str() calculation.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
I don't know whether it's a good approach. There are other fields in Item that prevent it from being reentrant.
Instead of solving it on a field-by-field basis we could create a hierarchy of "Item_runtime_context" objects. String values will naturally belong there too.