Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 Dec 1999 21:23:38 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        dmp@aracnet.com (D.M.P.)
Cc:        davids@webmaster.com, kris@hub.freebsd.org, jcm@dogma.freebsd-uk.eu.org, freebsd-chat@FreeBSD.ORG
Subject:   Re: threads....
Message-ID:  <199912022123.OAA28640@usr08.primenet.com>
In-Reply-To: <383084FF.606E228E@aracnet.com> from "D.M.P." at Nov 15, 99 02:11:11 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > > I am referring to the case in question: an ICQ client. ICQ is not a
> > > high-performance server application, and does not require parallelism for
> > > performance reasons.
> > 
> >         Agreed.
> 
> I'm by no stretch of the imagination familiar with how threading
> and process scheduling (is that the right phrase?) works beyond a
> basic definition, so please do excuse any blatant displays of
> ignorance. :)
> 
> Do all threads within a program have the same PID (ps-wise), or would
> they each have their own PID, or does it depend on how the program is
> written?


It depends on the implementation of the threading system.  Threads
are not guaranteed a unique PID; neither are they guaranteed a
non-unique PID.  They are only guaranteed a unique thread ID within
a given multithreaded process.


> What about in the case where you have multiple live chat and file
> transfers going at once, where you have multiple seperate tasks, each
> with their own TCP connection?  Does threading them help prevent one
> task from preempting another, or would that only be the case where
> each thread is it's own process with a unique PID?

This depends on your scheduling policy.  See the pthreads man
pages for details.  As a general rule, however, all threads
scheduling is supposed to assume that it may be preempted (that's
why there are threads mutexes and semaphores: to control race
conditions in case of preemption).  One of the reasons that the
Netscape browsers on the Macintosh and FreeBSD have serious
problems is that they assume that the underlying implementation
will allow a running thread to run to completion, so they can
lock up (especially while running Java, especially while running
the non-reentrant, threads unsafe, GIF decoder).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


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?199912022123.OAA28640>