Skip site navigation (1)Skip section navigation (2)
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>