From owner-freebsd-hackers@freebsd.org Wed Jan 2 01:56:18 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 447B214311D2 for ; Wed, 2 Jan 2019 01:56:18 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78E966D2AB; Wed, 2 Jan 2019 01:56:17 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id AE6D3BABBF; Wed, 2 Jan 2019 02:56:13 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1ZDaoz__tMh; Wed, 2 Jan 2019 02:56:12 +0100 (CET) Received: from [192.168.11.152] (unknown [192.168.11.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id C51F0BABB7; Wed, 2 Jan 2019 02:56:12 +0100 (CET) Subject: Re: Using kqueue with aio_read/write To: Alan Somers Cc: FreeBSD Hackers References: <8753521a-4555-ec2a-5efc-dee2660b4d9b@digiware.nl> From: Willem Jan Withagen Message-ID: <969d9a38-d3dd-78d0-c974-ba14ec4747db@digiware.nl> Date: Wed, 2 Jan 2019 02:56:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: nl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2019 01:56:18 -0000 On 28/12/2018 02:47, Alan Somers wrote: > On Thu, Dec 27, 2018 at 6:15 PM Willem Jan Withagen wrote: >> Hi, >> >> Im trying to understand why I cannot get so code to work. >> This is the smallest extract I can make to show my problem. >> >> I would expect the kevent() call to return every timeo tick. >> Even if I tell it NOT to time-out I get these spurts of errors >> >> Since there is nothing to trigger the AIO-event, I would expect kqueue >> to hold indefinitly. >> >> But it does not generate anything other than errors >> And instead it repeatedly complains that there is a permission error: >> get_events_kevent: EV_Error(1) kevent(): Operation not permitted >> >> But I'm not getting where that would the case... >> >> Surely a pilot error, but I do overlook it al the time. >> So suggestions are welcome. >> >> Thanx, >> --WjW >> >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> #define BUFFER_SIZE 512 >> #define MAX_EVENTS 32 >> >> #define FILENAME "/tmp/aio_test" >> char filename[256]; >> int fd; >> int done = 0; >> >> void get_events_kevent(int fd, int kq) >> { >> printf("get_events function fd = %d, kq = %d\n", fd, kq); >> int i = 0, errcnt = 0, err, ret, reterr, rev; >> int search = 1; >> >> int timeout_ms = 10; >> struct timespec timeo = { >> timeout_ms / 1000, >> (timeout_ms % 1000) * 1000 * 1000 >> }; >> struct kevent filter[16]; >> struct kevent changed[16]; >> >> EV_SET(&filter[0], fd, EVFILT_AIO, >> EV_ADD, >> 0, 0, 0 ); > > This is the first problem. There's no need to explicitly set > EVFILT_AIO on the kqueue. It gets set by the aio_read(2) or similar > syscall. And this invocation wouldn't be correct anyway, because for > AIO the ident field refers to the address of the struct aiocb, not the > file descriptor. If the only events you care about are AIO, then you > can pass NULL as the filter argument to kevent. I suspect this is the > cause of your problem. The kernel probably thinks you're trying to > register for an aiocb that's outside of your address space or > something like that. > > >> while (!done) { >> printf("+"); >> rev = kevent(kq, filter, 1, changed, 16, 0); //&timeo); >> if (rev < 0) { >> perror("kevent error"); >> } else if (rev == 0) { >> printf("T"); >> } else { >> printf("rev(%d)\n", rev); >> if (changed[0].flags == EV_ERROR) { >> errno = changed[0].data; >> printf( "%s: EV_Error(%d) kevent(): %s\n", __func__, errno, >> strerror(errno)); >> memset(&changed[0], 0, sizeof(struct kevent)); >> } else { >> err = aio_error((struct aiocb*)changed[0].udata); > > No need to call aio_error(2) after kevent(2) returns. You can go > straight to aio_return. aio_error shouldn't hurt, but it isn't > necessary. According to kevent(2) calling kevent can return errors on the called aio_calls. It then returns with EV_ERROR in flags, and errno is stored in the event.data. But what would be going on when the event's flag contains EV_ERROR but event's data is still 0??? the udata field still seems to point to the aio data that was passed into the aio block when calling aio_read(). Should I ignore this as a non-error? --WjW