Date: Mon, 21 Nov 2005 04:42:01 -0800 From: ray@redshift.com To: "Konstantin Prokazoff" <kprokazov@svr.kiev.ua>, <freebsd-hackers@freebsd.org> Subject: Re: poll()/select() Message-ID: <3.0.1.32.20051121044201.00aa1490@pop.redshift.com> In-Reply-To: <0a7a01c5ee75$b300b700$0c02010a@svr012>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:29 AM 11/21/2005 +0200, Konstantin Prokazoff wrote: | Welcome everybody, | | have a strange issue under 5.x/6.x (checked). | When using a poll()/select() mechanism, which in kernel based on | selrecord/selwakeup (pollscan, kern_select) functions, we have deadlock on | sellock mutex on heavy load (recursive lock on non-recursive mutex). Have | anyone seen this? Deadlock can be reached only if kernel w'be compiled with | debugger, because in different case system locks, your can't login, etc. | Maybe one path to resolve - change behavour of sched_lock & sellock mutexes | block/unblock order. | Thnx in advance & for comments. | | Best regards, | Konstantin Prokazoff | Center Of Excellence, S_V_R Ltd., Kyiv HQs, Ukraine | Official business-partner & DevConnect member of Avaya Inc. | Regional development & support center of Digium Inc. | Tel. +38 044 244 1181, ext. 1038 | Fax. +38 044 234 0455 The only thing I can add is that a sys admin friend of mine did try using the poll/select to increase performance and had to finally abandon it due to instability problems under load. I've never tried it first hand myself. Not sure if that helps you. Ray
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.1.32.20051121044201.00aa1490>