Re: Kevent(2) doesn't notify about EVFILT_WRITE filter event
John-Mark Gurney wrote on 01.12.2005 10:55 MSK: JMG> Dmitry Agaphonov wrote this message on Thu, Dec 01, 2005 at 15:06 +0300: JMG> > I have two applications (server A and server B, A asks B for data to JMG> > serve clients) communicating via UNIX-domain socket. Testing local JMG> > clients interact to server A via UNIX-domain sockets too. Server A JMG> > uses kqueue(2) to handle clients and server B. JMG> > JMG> > When about 20 clients start requesting server A without delay, kevent(2) JMG> > doesn't notify about requested EVFILT_WRITE after only few small JMG> > requests. JMG> > JMG> > JMG> > Dumping kevent(2) changelist and eventlist gives the following: JMG> > JMG> > Server A asks for write event (with EV_ONESHOT flag set) to server B: JMG> > [13:45:36][DBG] Changing SysEvent: ident: 8, filter: -2, flags: 0x11, fflags: 0, data: 0, udata: 0x0 JMG> > [13:45:36][DBG] Received SysEvent: ident: 8, filter: -2, flags: 0x11, fflags: 0, data: 8192, udata: 0x0 JMG> > JMG> > So, the socket send buffer has 8192 bytes free. Then A sends 426 JMG> > bytes to B. JMG> > JMG> > Then server A asks for write event again: JMG> > [13:45:36][DBG] Changing SysEvent: ident: 8, filter: -2, flags: 0x11, fflags: 0, data: 0, udata: 0x0 JMG> > JMG> > After this, EVFILT_WRITE event is not returned. Noone else writes to JMG> > this socket. How it is possible? JMG> JMG> are you checking the output from the kevent that sets the sysevent? JMG> kevent if you do something "stupid" like set a _ONESHOT in kevent, and JMG> provide space for events to be returned to userland, the _ONESHOT will JMG> be immediately returned and cleared... JMG> JMG> It could also be an error is trying to be set, but can't be if you JMG> don't provide return space... so w/o seeing your code, I'd make sure JMG> when setting you are able to receive some events, and check what events JMG> you get back... Not in this, but that was my fault. Thank you for answer. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Kevent(2) doesn't notify about EVFILT_WRITE filter event
Hello all, I have two applications (server A and server B, A asks B for data to serve clients) communicating via UNIX-domain socket. Testing local clients interact to server A via UNIX-domain sockets too. Server A uses kqueue(2) to handle clients and server B. When about 20 clients start requesting server A without delay, kevent(2) doesn't notify about requested EVFILT_WRITE after only few small requests. Dumping kevent(2) changelist and eventlist gives the following: Server A asks for write event (with EV_ONESHOT flag set) to server B: [13:45:36][DBG] Changing SysEvent: ident: 8, filter: -2, flags: 0x11, fflags: 0, data: 0, udata: 0x0 [13:45:36][DBG] Received SysEvent: ident: 8, filter: -2, flags: 0x11, fflags: 0, data: 8192, udata: 0x0 So, the socket send buffer has 8192 bytes free. Then A sends 426 bytes to B. Then server A asks for write event again: [13:45:36][DBG] Changing SysEvent: ident: 8, filter: -2, flags: 0x11, fflags: 0, data: 0, udata: 0x0 After this, EVFILT_WRITE event is not returned. Noone else writes to this socket. How it is possible? When I only turn on some additional logging which makes nothing but logs something and thus makes some small delays between kevent(2) calls -- all works fine, kevent(2) notifies about all write events. Could anyone please give thoughts about why kevent(2) can behave so? I have definitely no idea where the problem can be. This happens on FreeBSD 4.11-STABLE (cvsup'ed Nov 20 2005), SMP kernel, P4 with HT. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Shared memory permissions question
Hello, I have user A from group G creating shared memory M with permissions 0060. After this, A fails to attach M due to permission denied. However, another user B from the same group G successfully attaches M. User A manages to attach only if permissions 0600 added for M. Why the system disregards group permissions for user A? Is it correct behaviour? This is happening on FreeBSD 4.11-STABLE. Thanks in advance. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Kernel threads & libc
Hello all, I'm forced to implement kernel threads in application not via LinuxThreads library (because it doesn't compile on FreeBSD 4.10 with gcc-3.4.4, too much errors while processing /usr/src code), but using rfork_thread(3). And the main question I currently stuck on is which libc functions I need to wrap to make them thread-safe and reentrant on multiprocessor systems, since rfork_thread(3)s are created with RFMEM flag and libc_r is not used. Could somebody please give ideas or point me to the appropriate reading? Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kqueue & pthread
On Wed, 9 Feb 2005 10:51:36 -0500 Brian Fundakowski Feldman <[EMAIL PROTECTED]> wrote: BFF> The LinuxThreads library seems to be the best-supported way. I don't think BFF> that there should be legal/licensing issues using it. Unfortunatelly, I can't use the LinuxThreads library, it simply does not compile on FreeBSD 4.10 (and I assume that on latest 4.x too) with gcc-3.4.4. Errors appear when it's building code from /usr/src tree with the newer compiler. FreeBSD 4.x is a mandatory target platform and using gcc-3.4 is a strong wish. So, I'm going to have kernel threads via rfork_thread(3) and the main question I stuck on is which libc functions I need to wrap to make them thread-safe and reentrant on multiprocessor systems, since rfork_thread(3)s are created with RFMEM flag and libc_r is not used. Could one give ideas or point where to read? Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kqueue & pthread
On Wed, 9 Feb 2005 09:49:24 -0500 Brian Fundakowski Feldman <[EMAIL PROTECTED]> wrote: BFF> Since you're using user threads, not kernel threads, the kernel can only BFF> have one "object" (poll or select list, or kqueue file descriptor) to wait BFF> upon at any given time. Since kqueues are pollable, what happens is BFF> that the kqueue along with every other fd being polled/selected are all BFF> polled by a single poll(2) system call. Yes, your kqueue is being used, BFF> but it has an indirection of another poll(2) system call determining BFF> when your kevent(2) thread should be woken up. Brian, thank a lot for your explanation! So, pthreads since they are user threads do not provide concurrency on multiprocessor systems? And by the way, are there another ways to have kernel threads in FreeBSD 4.x applications, rather than use LinuxThreads port or implement it via rfork'ed processes? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kqueue & pthread
Hello all, There's a server application that use non-bloking sockets with kqueue in its main thread and blocking I/O in two auxiliary threads. While watching the server in top(1), I've noticed that it is in the 'poll' state instead of 'kqread'. And breaking the server process execution in the debugger drops to __sys_poll() instead of kevent(). So, the question is: does it really mean that linking to libc_r forces me to use poll (somehow internally?) and lose the benefit from using kqueue system? I'm using gcc-3.4.4 with -pthread option. FreeBSD version is 4.10-STABLE. Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
