>
>I have run threaded tests on Solaris with over 30,000 connections without
>problems, other than kernel deadlock due to resource starvation when
>stuffing too many kernel-side socket buffers with data.
>
Well there's your solution then. With Solaris you can multiplex
hundreds/thousands of use
In message <[EMAIL PROTECTED]> "Brian O'Shea" writes:
: I was under the impression that, because user thread scheduling is done
: in user mode, a thread that goes to sleep calling a blocking read()
: system call will put the entire process to sleep until that read()
: returns (and so all user thre
A G F Keahan wrote:
>
> > On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote:
> > >
> > > This design isn't ideal on any OS, but the fact that you do significant
> > > processing every time a request arrives on a socket probably hides most of
> > > the inefficiency due to thread switchin
Both Solaris and NT have good thread implementations:
http://www.usenix.org/publications/library/proceedings/usenix-nt98/zabatta.html
Read this paper -- There is something about NT
threads implementation which has never been released
in any books!
> the goal is to
> do better than NT
> (which
> Linux runs into problems at less than 4000 threads because of a limit on
> the total number of processes, even if the thread stack size is decreased.
16xxx if you use a 2.3.99pre-x kernel?
At least I thought that that was being mentioned as one of the major new things in
2.4.x kernels.
Marco
> From [EMAIL PROTECTED] Tue Apr 25 06:02:09 2000
> Date: Tue, 25 Apr 2000 05:23:39 +0300
> From: A G F Keahan <[EMAIL PROTECTED]>
> To: "Richard Seaman, Jr." <[EMAIL PROTECTED]>
> Cc: Jason Evans <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re:
On Mon, Apr 24, 2000 at 09:58:49PM -0500, Chris Costello wrote:
> On Monday, April 24, 2000, Brian O'Shea wrote:
> > Yea, I took a look at lib/libc_r/uthread/uthread_read.c too, but it
> > didn't paint the whole picture for me. Specifically, I couldn't find
> > the definition for the _thread_sys_
On Mon, Apr 24, 2000 at 05:07:00PM -0500, Chris Costello wrote:
>FreeBSD's threads implement has its own read() function which
> will make a non-blocking read() call (using the _real_ syscall)
> for the specified amount of bytes. Now a non-blocking read()
> call fails unless all the data in n
On Monday, April 24, 2000, Brian O'Shea wrote:
> Yea, I took a look at lib/libc_r/uthread/uthread_read.c too, but it
> didn't paint the whole picture for me. Specifically, I couldn't find
> the definition for the _thread_sys_read() function. It looks like the
> polling magic to which Jason Evans
Hello,
I would like to suggest to read the following articles
at http://www.cs.wustl.edu/~schmidt/report-doc.html
(he has there a ps doc for each article)
13.Comparing Alternative Programming Techniques for Multi-threaded Servers --
the Thread-per-Session Concurren
Jason and Richard,
thank you very much for your explanations of libc_r and
LinuxThreads. Due to the significant processing time of each request
(typically between 50-800ms, averaging 100ms), I doubt that FreeBSD's
threads would perform any worse than if I forked a separate proce
> Linux runs into problems at less than 4000 threads because of a limit on
> the total number of processes, even if the thread stack size is decreased.
I believe this restriction was eliminated in the 2.2.x series.
-MB
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-
On Mon, Apr 24, 2000 at 02:11:11PM -0700, Jason Evans wrote:
> > Could you elaborate? The text that I am using [1] warns about blocking
> > system calls putting the process (and thus all user threads) to sleep.
> > This book has no FreeBSD specific information, so anything specific to
> > FreeBSD
On Mon, Apr 24, 2000 at 04:44:05PM -0500, Richard Seaman, Jr. wrote:
> On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote:
> > FreeBSD's threads should perform adequately given the design of your program
> > and the hardware you listed. Actually trying it on the various operating
> > sys
On Monday, April 24, 2000, Brian O'Shea wrote:
> On Mon, Apr 24, 2000 at 06:13:53AM -0400, Daniel Eischen wrote:
> > On Mon, 24 Apr 2000, Brian O'Shea wrote:
> > >
> > > I was under the impression that, because user thread scheduling is done
> > > in user mode, a thread that goes to sleep calling
On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote:
> On Mon, Apr 24, 2000 at 05:17:10AM +0300, A G F Keahan wrote:
> > I am currently porting a multithreaded TCP server from NT (yech!) to
> > UNIX using pthreads. The server has a fairly straightforward design --
> > it opens a thread fo
On Mon, Apr 24, 2000 at 06:13:53AM -0400, Daniel Eischen wrote:
> On Mon, 24 Apr 2000, Brian O'Shea wrote:
> >
> > I was under the impression that, because user thread scheduling is done
> > in user mode, a thread that goes to sleep calling a blocking read()
> > system call will put the entire pr
On Mon, 24 Apr 2000, Brian O'Shea wrote:
> On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote:
> >
> > FreeBSD's libc_r does not use clone() or anything similar. Instead, it is
> > a userland call conversion library that multiplexes threads in a single
> > process. This style of threa
On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote:
>
> FreeBSD's libc_r does not use clone() or anything similar. Instead, it is
> a userland call conversion library that multiplexes threads in a single
> process. This style of threads library should perform well for the type of
> app
On Mon, Apr 24, 2000 at 05:17:10AM +0300, A G F Keahan wrote:
> I am currently porting a multithreaded TCP server from NT (yech!) to
> UNIX using pthreads. The server has a fairly straightforward design --
> it opens a thread for each connection, and each thread spends most of
> its life blocked
20 matches
Mail list logo
