Re: [HACKERS] New s_lock.h fails on HPUX with gcc
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] New s_lock.h fails on HPUX with gcc |
Дата | |
Msg-id | 2112.899997361@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] New s_lock.h fails on HPUX with gcc (dg@illustra.com (David Gould)) |
Список | pgsql-hackers |
dg@illustra.com (David Gould) writes: >> This is an entirely bogus assumption not only for HPUX, but for any >> other architecture that has gcc available. > Not quite. Only for architectures whose S_LOCK code is identical under > both GCC and non GCC. Solaris for example has different code for the GCC > case vs the non GCC case. Quite true. But it seems to me that the default assumption should be that an architecture has the same code for GCC and other compilers; first you get it going, then maybe you think about using asm inline to optimize under GCC. With the existing structure of s_lock.h, the easiest path is to miss out one case or the other completely. Your example seems to be that all the x86/GCC platforms can be consolidated, but AFAICS that's true whether you make the outer conditional be GCC or platform. > Still, your point about making it easy to miss some possibilities is well > taken. On the other hand, the #if block per platform gets pretty clumsy > when you have a half dozen major platforms that use the same compiler. But cutting&pasting to start adding support for a new platform is pretty simple and straightforward if there is only one block of code to look at. There might be a tad more duplicated code after a while, but it'd be easy to understand and hence easy to modify. I think the direction you are headed reduces code duplication at a very high price in confusion and fragility. > So if you have a better idea than I outlined just above, or an objection, > I am very happy to hear it and try to make it right. But, let me know soon > otherwise I will put together a patch using the above method this weekend. Since I'm not doing the work, I'll shut up now and let you do what you think best ;-) regards, tom lane
В списке pgsql-hackers по дате отправления: