Date: Thu, 15 Jul 1999 04:21:44 -0500 (EST) From: Alfred Perlstein <bright@rush.net> To: David Schwartz <davids@webmaster.com> Cc: Tani Hosokawa <unknown@riverstyx.net>, chat@FreeBSD.ORG Subject: RE: Known MMAP() race conditions ... ? Message-ID: <Pine.BSF.3.96.990715041529.14320Q-100000@cygnus.rush.net> In-Reply-To: <000301bece7a$ededf700$021d85d1@youwant.to>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 14 Jul 1999, David Schwartz wrote: > In other words, you only block when you absolutely need the data in order to > continue processing that one job. > > > So, eventually you're going to have to do a read, and if you hang then, > > all jobs stall. > > No, the current job stalls. How does one job stalling affect the others? > Remember, you have a poll of threads (whose size is dynamically adjusted) > pulling jobs out of the pool. This would work a lot better if you just had 2xCPU non-threaded processes (maybe more) right now you are re-wrapping the threading code's non-blocking code with your own non-blocking i/o code, this is not a good idea. If you are using FreeBSD, you may want to look at a stripped down version of the kernel threads package afaik the URL is: http://lt.tar.com/ even so, you are doubling the work needed to be done for non-blocking operations. If you have a lot of shared data to manipulate, you may want to steal the freebsd native threads mutex functions as they can do atomic memory ops for achiving sync. -Alfred Perlstein - [bright@rush.net|bright@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990715041529.14320Q-100000>