Re: PATCH: pgbench - option to build using ppoll() for largerconnection counts
От | Robert Haas |
---|---|
Тема | Re: PATCH: pgbench - option to build using ppoll() for largerconnection counts |
Дата | |
Msg-id | CA+TgmoZLs5gajFDi0rD6aoL4=4uRRDM=c09UEUyPjaWThxwipw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PATCH: pgbench - option to build using ppoll() for largerconnection counts (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: PATCH: pgbench - option to build using ppoll() for largerconnection counts
|
Список | pgsql-hackers |
On Wed, Nov 29, 2017 at 8:10 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote: > My point is consistent with my other advice which is to hide the stuff in > functions with identical (or compatible) signatures, so that the only place > where it would differ would be in the functions, where greping would work. > > #ifdef USE_POLL > // pool specific stuff > #define SOME_TYPE v1_type (or typedef) > void do_stuff(v1_type * stuff) { ... } > ... > #else /* default to SELECT */ > // select specific stuff > #define SOME_TYPE v2_type (idem) > void do_stuff(v2_type * stuff) { ... } > ... > #endif > > Then later the code is not specific to poll or select, eg: > > SOME_TYPE mask; > do_stuff(mask); > do_other_stuff(...); > if (is_ready(mask, ...)) { ... } Yeah, that sort of style would be OK with me. But I wouldn't like: struct blah { #ifdef FOO int doohicky; #else char *doohicky; }; ...because now any place in the code where you see "doohicky" you don't immediately know whether it's an int or a char * -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: