Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA03968; Wed, 7 Feb 96 05:00:36 EST
Received: from aztec.co.za by MIT.EDU with SMTP
	id AA24706; Wed, 7 Feb 96 05:00:12 EST
Received: from ccii.co.za [196.3.224.65] by aztec.co.za with smtp
	(Smail3.1.29.1 #2) id m0tk6ek-000anYC; Wed, 7 Feb 96 11:59 EET
Received: by ccii.co.za (Smail3.1.28.1 #1)
	id m0tk6aO-0002C7C; Wed, 7 Feb 96 11:54 GMT+0200
Message-Id: <m0tk6aO-0002C7C@ccii.co.za>
From: soren@ccii.co.za (Soren Aalto)
Subject: Re: pthreads
To: proven@MIT.EDU (Christopher Provenzano)
Date: Wed, 7 Feb 1996 11:54:46 +0200 (GMT+0200)
In-Reply-To: <9602061832.AA10871@yaz-pistachio.MIT.EDU> from "Christopher Provenzano" at Feb 6, 96 01:32:57 pm
Reply-To: soren@aztec.co.za
X-Disclaimer: The wheel is still turning but the hamster is dead
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2080      

One day, not so long ago, Christopher Provenzano wrote:
> 
> 
> I read on c.o.l that you were having trouble with pthreads and linux
> and was wondering which version of pthreads you were using?
> 
> CAP

Hi -- thanks for taking an interest...I don't know where the problem lies,
exactly, it is probably elsewhere.  However, for the record, I am using
the sources in pthreads-1_51_0.tar.gz. The only trouble I had in building
the library was that it seems that gcc2.6.3 doesn't like compiling a
function called creat.  When I renamed creat to creat_PT, the library
compiled fine.  I know this is a bit of a problem, but I'm not using creat
at the moment, so it shouldn't affect me. 

I have been writing a few tests to see what does/doesn't work. My original
speculations were wrong:  specifically, I have verified that: 

-select does work with FIFOs
-select works with FIFOs using pthreads
-multiple threads blocking on reading FIFOs also work

...and suprising to me, these continue to work even if one of the 
other threads is CPU bound (idle looping).  You use SIGVTALRM to do
time-slicing, right? 

What has been confusing me is that I was using macros that evaluated to
fprintf(stderr...) to dump a lot of trace I/O.  I think that some of these
were compiled with /usr/include/stdio.h and others were compiled with
.../pthreads/include/stdio.h, and this is not good for the confusion
quotient.  I found that I would get I/O out of some modules, but not
others.  Also, it is hard to follow stuff in the debugger when ever bit of
trace I/O causes a potential reschedule.  So, I changed the macros and
wrote a daemon to get the trace I/O through shared memory segments (I come
from an embedded systems background, so it seems only natural).  Hopefully
this should clear up where I am going wrong. 

Thanks,

-----------------------------------------------------------------
Soren Aalto                                Email:  soren@ccii.co.za
Development Engineer                       Ph:     +27-21-683-5490
CCII Systems, Kennilworth, South Africa    Fax:    +27-21-683-5435
