On Mon, Nov 27, 2000 at 09:38:37AM +0900, itojun@iijlab.net wrote:

> 
> >2) Without using fork() or daemon() to detach it, using
> >   & instead at command invocation, it works better,
> >   however concurrent pthreads() execute sequencially
> >   rather than simultaniously when several connections
> >   are served, despite proper pthread_attr initialization.
> 
> 	(aside from fork/daemon issue)
..
> 
> 	(NOTE: unless you have multiple CPUs, your threads will be executed one
> 	at a given moment, on any operating systems.  you are seeing imaginary
> 	simultaneous execution because of context switches).
> 
> 	if my guess is wrong, could you tell me what you've expected from
> 	threaded execution ("simultaneously")?
> 

Thank you very much for your quick reply itojun,

On Linux and FreeBSD the pthreads appear to run simultaniously, permitting to
serve several connections at once, independantly, just as fork() would do.
For the moment it seems that if two requests are handled at the same time,
until the first one is done with, the second one will keep waiting...

As you said, unless it runs on several CPUs it only can be an illusion of
simultanious multitasking, but the illusion usually was real, and threads
would be able to serve much more connections simultaniously than using
fork()

Would the illusion of multitasking be lost because of the lack of pthreads
support into the kernel? Maybe that because of this the various threads would
now be spinned unless they are fully done with...

When compiled on linux, 10 connections would be served at once as fast as
one would, without noticing any lag.. currently one connection must be closed
for the second to start responding, etc. Thus acting somewhat like a queue
rather than as multitasking threads, despite the pthread_set_attr_detachstate()

Matthew Mondor