Your right, I did send this to the 
wrong list. I have written the 
driver for FreeBSD, but I also
wrote one for OpenBSD, which
I think is much closer to NetBSD
than FreeBSD. I will eventually 
also port it to NetBSD.

I do not have that option of
writing the application with
multi-processes instead of threads.

I am using Apache and I am 
accelerating the OpenSSL crypto
calls. Apache is multi-threaded.

----- Original Message ----- 
From: "Thor Lancelot Simon" <tls@rek.tjls.com>
To: "mike varga" <mike.varga@cavium.com>
Cc: <tech-kern@netbsd.org>
Sent: Thursday, September 13, 2001 3:36 PM
Subject: Re: FD_LOCK, pthreads and drivers


> On Thu, Sep 13, 2001 at 02:27:02PM -0700, mike varga wrote:
> > I noticed that while testing the driver I wrote
> > for a crypto device, that only one thread
> > can be executing within the context of
> > my driver at a time.
> > 
> > The problem is that the pthreads library 
> > replaces the ioctl with another that exclusively
> > locks the file descriptor with calls to FD_LOCK/
> > FD_UNLOCK.
> 
> NetBSD does not currently contain a POSIX threads library, so
> this cannot be a problem with NetBSD per se.  It's possible that
> the third-party thread library you're using does this, but that
> really doesn't have anything to do with the NetBSD kernel!
> 
> As I expect you know, multiprogramming on Unix systems generally
> uses multiple processes, with independent address spaces (parts
> of which can be shared under program control) rather than multiple
> threads executing within the same address space.  If your driver is
> fully reentrant, can't you achieve decent parallelism using this
> model?
> 
>