Messages in this thread |  | | From | "Anil Kumar" <> | | Subject | RE: threading question | | Date | Fri, 15 Jun 2001 16:59:00 +0530 |
| |
Since while using only a small subset of primitives provided by the pthreads the burden for the other primitive maintanence is much more so i too feel when we use only a small part its better to implement in our own requiredd way for performance issues.
-----Original Message----- From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of bert hubert Sent: Friday, June 15, 2001 12:32 AM To: Alan Cox Cc: Kip Macy; ognen@gene.pbi.nrc.ca; linux-kernel@vger.kernel.org Subject: Re: threading question
On Thu, Jun 14, 2001 at 07:28:32PM +0100, Alan Cox wrote:
> There are really only two reasons for threaded programming. > > - Poor programmer skills/language expression of event handling
The converse is that pthreads are:
- Very easy to use from C at a reasonable runtime overhead
It is very convenient for a userspace coder to be able to just start a function in a different thread. Now it might be so that a kernel is not there to provide ease of use for userspace coders but it is a factor.
I see lots of people only using: pthread_create()/pthread_join() mutex_lock/unlock sem_post/sem_wait no signals
My gut feeling is that you could implement this subset in a way that is both fast and right - although it would not be 'pthreads compliant'. Can anybody confirm this feeling?
Regards,
bert
-- http://www.PowerDNS.com Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |