"Ralf S. Engelschall" wrote:
> On Mon, Oct 09, 2000, flobro wrote:
>
> > Not only do detached threads not run, but the unmodified test-pthreads
> > program - each thread does not start executing until the pthread_join is
> > called. Every thread is starting at 1 AFTER the join is called. I would
> > have expected each thread to start executing immediately after the
> > pthread_create call.
> >
> > ...I changed the test-pthreads program to use detached threads and the
> > ...threads never execute.
> > ...(I have pth 1.3.7 with RH 6.2)
> > ...The normal version of the test program works.
> > ...
> > ...Anybody seen this before?
>
> I think you problem is that you missed the fact that Pth (and this way
> its Pthread API) is (intentionally) non-preemptive. So, a thread cannot
> run "immediately" without giving it a chance to run. The "chance" you
> give is the next pthread_* or pth_* function call. In the test_pthread.c
> this is sleep(), but only if you built Pth with --enable-syscall-soft.
> If you leave out --enable-syscall-soft, the next call is pthread_join(),
> of course. And that's what you observed...
>
> Ralf S. Engelschall
> [EMAIL PROTECTED]
> www.engelschall.com
> ______________________________________________________________________
> GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager (Majordomo) [EMAIL PROTECTED]
What I did not say is that my main thread performs a blocking read on the
keyboard at that point, and that works, but the sub thread never runs. I
played with the configuration with --enable-syscall-hard and my thread now
runs. I guess that there is some confusion on my part between syscall-hard +
soft and what differences mctx methods make.
Thanks for the reply
Floyd
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]