Re: kqueue
От | Marko Tiikkaja |
---|---|
Тема | Re: kqueue |
Дата | |
Msg-id | 45539ad5-28ff-169f-1055-a8e269c1bdf9@joh.to обсуждение исходный текст |
Ответ на | Re: kqueue (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: kqueue
|
Список | pgsql-hackers |
On 2016-06-03 01:45, Thomas Munro wrote: > On Fri, Jun 3, 2016 at 4:02 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: >> Tom Lane wrote: >>> Andres Freund <andres@anarazel.de> writes: >>>>> pg_strtoi? >>> >>>> I think that's what Thomas did upthread. Are you taking this one then? >>> >>> I'd go with just "strtoint". We have "strtoint64" elsewhere. >> >> For closure of this subthread: this rename was committed by Tom as >> 0ab3595e5bb5. > > Thanks. And here is a new version of the kqueue patch. The previous > version doesn't apply on top of recent commit > a3b30763cc8686f5b4cd121ef0bf510c1533ac22, which sprinkled some > MAXALIGN macros nearby. I've now done the same thing with the kevent > struct because it's cheap, uniform with the other cases and could > matter on some platforms for the same reason. I've tested and reviewed this, and it looks good to me, other than this part: + /* + * kevent guarantees that the change list has been processed in the EINTR + * case. Here we are only applying a change list so EINTR counts as + * success. + */ this doesn't seem to be guaranteed on old versions of FreeBSD or any other BSD flavors, so I don't think it's a good idea to bake the assumption into this code. Or what do you think? .m
В списке pgsql-hackers по дате отправления: