httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname ( too long
Date Thu, 15 Feb 2018 19:41:17 GMT
On Thu, Feb 15, 2018 at 12:26 PM, Jim Jagielski <> wrote:
> It seems like some serious overhead to force a function call
> for each and every access to a struct field, especially if
> it's only so we can adjust those struct fields w/o a corresponding
> change in the ABI...

Why would you do that?

The only modules who would call these functions would be those making
a duplicate of the entire structure.

Why does this happen? mod_cluster rearranges shm slots, I'm guessing.
mod_ftp took a completely generic server_rec, duplicated it, then
changed the value of the document_root member, and seeded new
request_rec structures in response to ftp commands. There are many
examples of why a _create() accessor is a good thing for module
developers, but it's not impossible to imagine these modules having a
need to make _copy() of one of our structures.

However we solve, the function template could be macroized, e.g.

  AP_DECLARE(struct stype *) ap_##stype##_palloc(apr_pool_t *p); \
  AP_DECLARE(apr_size_t) ap_##stype##_sizeof(); \
  AP_DECLARE(void) ap_##stype##_copy(struct stype *new, struct stype *orig);

  AP_DECLARE(struct stype *) ap_##stype##_palloc(apr_pool_t *p) \
  { return apr_pcalloc(p, sizeof(struct stype)); } \
  AP_DECLARE(apr_size_t) ap_##stype##_sizeof() \
  { return sizeof(new); } \
  AP_DECLARE(void) ap_##stype##_copy(struct stype *new, struct stype *orig) \
  { return memcpy(new, orig, sizeof(struct stype)); }

The apr_stype_create() call has a whole lot more decorative things to
do by default, and can't really be macroized, but should be split as
necessary into context-free default initialization (ap_stype_create)
and the current phase-specific core logic (e.g. most of
core_create_conn as implemented today.)

View raw message