You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Zhao Yongming (Created) (JIRA)" <ji...@apache.org> on 2011/10/07 13:48:29 UTC
[jira] [Created] (TS-977) RecCore usage cleanup
RecCore usage cleanup
---------------------
Key: TS-977
URL: https://issues.apache.org/jira/browse/TS-977
Project: Traffic Server
Issue Type: Task
Components: Cleanup
Affects Versions: 3.1.2
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Minor
in RecCore.*
{code}
int RecGetRecordInt(const char *name, RecInt * rec_int, bool lock = true);
//-------------------------------------------------------------------------
// RecGetRecordXXX
//-------------------------------------------------------------------------
int
RecGetRecordInt(const char *name, RecInt *rec_int, bool lock)
{
int err;
RecData data;
if ((err = RecGetRecord_Xmalloc(name, RECD_INT, &data, lock)) == REC_ERR_OKAY)
*rec_int = data.rec_int;
return err;
}
{code}
and there is something heavy used:
{code}
//-------------------------------------------------------------------------
// Backwards Compatibility Items (REC_ prefix)
//-------------------------------------------------------------------------
#define REC_ReadConfigInt32(_var,_config_var_name) do { \
RecInt tmp = 0; \
RecGetRecordInt(_config_var_name, (RecInt*) &tmp); \
_var = (int32_t)tmp; \
} while (0)
#define REC_ReadConfigInteger(_var,_config_var_name) do { \
RecInt tmp = 0; \
RecGetRecordInt(_config_var_name, &tmp); \
_var = tmp; \
} while (0)
{code}
and a real case, the REC_ReadConfigInteger is renamed to IOCORE_ReadConfigInteger:
{code}
RecInt cache_config_threads_per_disk = 12;
#define IOCORE_ReadConfigInteger REC_ReadConfigInteger
IOCORE_ReadConfigInteger(cache_config_threads_per_disk, "proxy.config.cache.threads_per_disk");
{code}
my question is, why it is so complex in all these renaming? why not just:
{code}
RecGetRecordInt("proxy.config.cache.threads_per_disk", &cache_config_threads_per_disk);
{code}
brief talk with Leif, we may need to cleanup the use of REC_*. make it a small task here
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-977) RecCore usage cleanup
Posted by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-977:
-----------------------------
Fix Version/s: (was: 3.1.2)
3.1.3
> RecCore usage cleanup
> ---------------------
>
> Key: TS-977
> URL: https://issues.apache.org/jira/browse/TS-977
> Project: Traffic Server
> Issue Type: Task
> Components: Cleanup
> Reporter: Zhao Yongming
> Assignee: Zhao Yongming
> Priority: Minor
> Fix For: 3.1.3
>
>
> in RecCore.*
> {code}
> int RecGetRecordInt(const char *name, RecInt * rec_int, bool lock = true);
> //-------------------------------------------------------------------------
> // RecGetRecordXXX
> //-------------------------------------------------------------------------
> int
> RecGetRecordInt(const char *name, RecInt *rec_int, bool lock)
> {
> int err;
> RecData data;
> if ((err = RecGetRecord_Xmalloc(name, RECD_INT, &data, lock)) == REC_ERR_OKAY)
> *rec_int = data.rec_int;
> return err;
> }
> {code}
> and there is something heavy used:
> {code}
> //-------------------------------------------------------------------------
> // Backwards Compatibility Items (REC_ prefix)
> //-------------------------------------------------------------------------
> #define REC_ReadConfigInt32(_var,_config_var_name) do { \
> RecInt tmp = 0; \
> RecGetRecordInt(_config_var_name, (RecInt*) &tmp); \
> _var = (int32_t)tmp; \
> } while (0)
> #define REC_ReadConfigInteger(_var,_config_var_name) do { \
> RecInt tmp = 0; \
> RecGetRecordInt(_config_var_name, &tmp); \
> _var = tmp; \
> } while (0)
> {code}
> and a real case, the REC_ReadConfigInteger is renamed to IOCORE_ReadConfigInteger:
> {code}
> RecInt cache_config_threads_per_disk = 12;
> #define IOCORE_ReadConfigInteger REC_ReadConfigInteger
> IOCORE_ReadConfigInteger(cache_config_threads_per_disk, "proxy.config.cache.threads_per_disk");
> {code}
> my question is, why it is so complex in all these renaming? why not just:
> {code}
> RecGetRecordInt("proxy.config.cache.threads_per_disk", &cache_config_threads_per_disk);
> {code}
> brief talk with Leif, we may need to cleanup the use of REC_*. make it a small task here
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-977) RecCore usage cleanup
Posted by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-977:
-----------------------------
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please!
> RecCore usage cleanup
> ---------------------
>
> Key: TS-977
> URL: https://issues.apache.org/jira/browse/TS-977
> Project: Traffic Server
> Issue Type: Task
> Components: Cleanup
> Reporter: Zhao Yongming
> Assignee: Zhao Yongming
> Priority: Minor
> Fix For: 3.3.0
>
>
> in RecCore.*
> {code}
> int RecGetRecordInt(const char *name, RecInt * rec_int, bool lock = true);
> //-------------------------------------------------------------------------
> // RecGetRecordXXX
> //-------------------------------------------------------------------------
> int
> RecGetRecordInt(const char *name, RecInt *rec_int, bool lock)
> {
> int err;
> RecData data;
> if ((err = RecGetRecord_Xmalloc(name, RECD_INT, &data, lock)) == REC_ERR_OKAY)
> *rec_int = data.rec_int;
> return err;
> }
> {code}
> and there is something heavy used:
> {code}
> //-------------------------------------------------------------------------
> // Backwards Compatibility Items (REC_ prefix)
> //-------------------------------------------------------------------------
> #define REC_ReadConfigInt32(_var,_config_var_name) do { \
> RecInt tmp = 0; \
> RecGetRecordInt(_config_var_name, (RecInt*) &tmp); \
> _var = (int32_t)tmp; \
> } while (0)
> #define REC_ReadConfigInteger(_var,_config_var_name) do { \
> RecInt tmp = 0; \
> RecGetRecordInt(_config_var_name, &tmp); \
> _var = tmp; \
> } while (0)
> {code}
> and a real case, the REC_ReadConfigInteger is renamed to IOCORE_ReadConfigInteger:
> {code}
> RecInt cache_config_threads_per_disk = 12;
> #define IOCORE_ReadConfigInteger REC_ReadConfigInteger
> IOCORE_ReadConfigInteger(cache_config_threads_per_disk, "proxy.config.cache.threads_per_disk");
> {code}
> my question is, why it is so complex in all these renaming? why not just:
> {code}
> RecGetRecordInt("proxy.config.cache.threads_per_disk", &cache_config_threads_per_disk);
> {code}
> brief talk with Leif, we may need to cleanup the use of REC_*. make it a small task here
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-977) RecCore usage cleanup
Posted by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-977:
-----------------------------
Affects Version/s: (was: 3.1.2)
Fix Version/s: 3.1.2
> RecCore usage cleanup
> ---------------------
>
> Key: TS-977
> URL: https://issues.apache.org/jira/browse/TS-977
> Project: Traffic Server
> Issue Type: Task
> Components: Cleanup
> Reporter: Zhao Yongming
> Assignee: Zhao Yongming
> Priority: Minor
> Fix For: 3.1.2
>
>
> in RecCore.*
> {code}
> int RecGetRecordInt(const char *name, RecInt * rec_int, bool lock = true);
> //-------------------------------------------------------------------------
> // RecGetRecordXXX
> //-------------------------------------------------------------------------
> int
> RecGetRecordInt(const char *name, RecInt *rec_int, bool lock)
> {
> int err;
> RecData data;
> if ((err = RecGetRecord_Xmalloc(name, RECD_INT, &data, lock)) == REC_ERR_OKAY)
> *rec_int = data.rec_int;
> return err;
> }
> {code}
> and there is something heavy used:
> {code}
> //-------------------------------------------------------------------------
> // Backwards Compatibility Items (REC_ prefix)
> //-------------------------------------------------------------------------
> #define REC_ReadConfigInt32(_var,_config_var_name) do { \
> RecInt tmp = 0; \
> RecGetRecordInt(_config_var_name, (RecInt*) &tmp); \
> _var = (int32_t)tmp; \
> } while (0)
> #define REC_ReadConfigInteger(_var,_config_var_name) do { \
> RecInt tmp = 0; \
> RecGetRecordInt(_config_var_name, &tmp); \
> _var = tmp; \
> } while (0)
> {code}
> and a real case, the REC_ReadConfigInteger is renamed to IOCORE_ReadConfigInteger:
> {code}
> RecInt cache_config_threads_per_disk = 12;
> #define IOCORE_ReadConfigInteger REC_ReadConfigInteger
> IOCORE_ReadConfigInteger(cache_config_threads_per_disk, "proxy.config.cache.threads_per_disk");
> {code}
> my question is, why it is so complex in all these renaming? why not just:
> {code}
> RecGetRecordInt("proxy.config.cache.threads_per_disk", &cache_config_threads_per_disk);
> {code}
> brief talk with Leif, we may need to cleanup the use of REC_*. make it a small task here
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira