[
https://issues.apache.org/jira/browse/TS-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-795:
-----------------------------
Description:
Right now, we have a set of defines, and APIs, which can take either a "index"
to a size (used e.g. for an allocator index), or a real size. Both of these are
currently int64_t in all APIs and member variables, and in the implementations,
the usage are sometimes overloaded (i.e. we do "size" calculations on top of
the indexes, making for real confusing code).
There's also a lack of proper identification of what is an "size index" type
(or parameter), and what is a "size". This makes for risky code.
I think we should clean up all the implementations and APIs, as follow
1) Make proper names of all APIs and macros, clearly indicating if it's working
on a size index or a size.
2) Keep only the size types, parameters and macros using int64_t. Do not
overload "real" size over the size indexes.
3) We either make the size indexes an "int" (or even a short), or perhaps even
better an enum (like below). All APIs, parameters, and member variables that
refer to such size indexes would use this appropriate type.
{code}
enum BufferSizeIndex {
BUFFER_SIZE_INDEX_128 = 0,
BUFFER_SIZE_INDEX_256, /* 1 */
BUFFER_SIZE_INDEX_512, /* 2 */
BUFFER_SIZE_INDEX_1K, /* 3 */
BUFFER_SIZE_INDEX_2K, /* 4 */
BUFFER_SIZE_INDEX_4K, /* 5 */
BUFFER_SIZE_INDEX_8K, /* 6 */
BUFFER_SIZE_INDEX_16K, /* 7 */
BUFFER_SIZE_INDEX_32K, /* 8 */
BUFFER_SIZE_INDEX_64K, /* 9 */
BUFFER_SIZE_INDEX_128K, /* 10 */
BUFFER_SIZE_INDEX_256K, /* 11 */
BUFFER_SIZE_INDEX_512K, /* 12 */
BUFFER_SIZE_INDEX_1M, /* 13 */
BUFFER_SIZE_INDEX_2M, /* 14 */
/* These have special semantics */
BUFFER_SIZE_NOT_ALLOCATED,
};
{code}
was:
Right now, we have a set of defines, and APIs, which can take either a "index"
to a size (used e.g. for an allocator index), or a real size. Both of these are
currently int64_t in all APIs and member variables, and in the implementations,
the usage are sometimes overloaded (i.e. we do "size" calculations on top of
the indexes, making for real confusing code).
There's also a lack of proper identification of what is an "size index" type
(or parameter), and what is a "size". This makes for risky code.
I think we should clean up all the implementations and APIs, as follow
1) Make proper names of all APIs and macros, clearly indicating if it's working
on a size index or a size.
2) Keep only the size types, parameters and macros using int64_t. Do not
overload "real" size over the size indexes.
3) We either make the size indexes an "int" (or even a short), or perhaps even
better an enum (like below). All APIs, parameters, and member variables that
refer to such size indexes would use this appropriate type.
{code}
enum BufferSizeIndex {
BUFFER_SIZE_INDEX_128 = 0,
BUFFER_SIZE_INDEX_256, /* 1 */
BUFFER_SIZE_INDEX_512, /* 2 */
BUFFER_SIZE_INDEX_1K, /* 3 */
BUFFER_SIZE_INDEX_2K, /* 4 */
BUFFER_SIZE_INDEX_4K, /* 5 */
BUFFER_SIZE_INDEX_8K, /* 6 */
BUFFER_SIZE_INDEX_16K, /* 7 */
BUFFER_SIZE_INDEX_32K, /* 8 */
BUFFER_SIZE_INDEX_64K, /* 9 */
BUFFER_SIZE_INDEX_128K, /* 10 */
BUFFER_SIZE_INDEX_256K, /* 11 */
BUFFER_SIZE_INDEX_512K, /* 12 */
BUFFER_SIZE_INDEX_1M, /* 13 */
BUFFER_SIZE_INDEX_2M, /* 14 */
/* These have special semantics */
BUFFER_SIZE_NOT_ALLOCATED,
};
{CODE}
> Clean up definitions and usage of buffer size indexes vs buffer sizes
> ---------------------------------------------------------------------
>
> Key: TS-795
> URL: https://issues.apache.org/jira/browse/TS-795
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Fix For: 3.1
>
>
> Right now, we have a set of defines, and APIs, which can take either a
> "index" to a size (used e.g. for an allocator index), or a real size. Both of
> these are currently int64_t in all APIs and member variables, and in the
> implementations, the usage are sometimes overloaded (i.e. we do "size"
> calculations on top of the indexes, making for real confusing code).
> There's also a lack of proper identification of what is an "size index" type
> (or parameter), and what is a "size". This makes for risky code.
> I think we should clean up all the implementations and APIs, as follow
> 1) Make proper names of all APIs and macros, clearly indicating if it's
> working on a size index or a size.
> 2) Keep only the size types, parameters and macros using int64_t. Do not
> overload "real" size over the size indexes.
> 3) We either make the size indexes an "int" (or even a short), or perhaps
> even better an enum (like below). All APIs, parameters, and member variables
> that refer to such size indexes would use this appropriate type.
> {code}
> enum BufferSizeIndex {
> BUFFER_SIZE_INDEX_128 = 0,
> BUFFER_SIZE_INDEX_256, /* 1 */
> BUFFER_SIZE_INDEX_512, /* 2 */
> BUFFER_SIZE_INDEX_1K, /* 3 */
> BUFFER_SIZE_INDEX_2K, /* 4 */
> BUFFER_SIZE_INDEX_4K, /* 5 */
> BUFFER_SIZE_INDEX_8K, /* 6 */
> BUFFER_SIZE_INDEX_16K, /* 7 */
> BUFFER_SIZE_INDEX_32K, /* 8 */
> BUFFER_SIZE_INDEX_64K, /* 9 */
> BUFFER_SIZE_INDEX_128K, /* 10 */
> BUFFER_SIZE_INDEX_256K, /* 11 */
> BUFFER_SIZE_INDEX_512K, /* 12 */
> BUFFER_SIZE_INDEX_1M, /* 13 */
> BUFFER_SIZE_INDEX_2M, /* 14 */
> /* These have special semantics */
> BUFFER_SIZE_NOT_ALLOCATED,
> };
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
