On Wed, Aug 09, 2000, Jonas Bulow wrote:
> I have troubles with the pth_usleep. I pin pointed down the problem to
> the program below.
>
> Running it (pth-1.3.7 on FreeBSD 4.1) result in:
> ibc usleep
> Time elapsed: 2.018674 sec
> Time elapsed: 2.019807 sec
> pth_usleep
> Time elapsed: 2.009818 sec
> **Pth** SCHEDULER INTERNAL ERROR: no more thread(s) available to
> schedule!?!?
> Abort(core dumped)
>
> Why?
>
> Shouldn't pth_usleep behave as usleep? usleep sleeps for a maximum of
> 2^32-1 usec (~71 minutes) while pth_usleep breaks at 2000080 usecs. Why
> 2000080?
Hmmm... I tried your test program under the same environment:
| :> /tmp/pth/bin/pth-config --version
| GNU Pth 1.3.7 (29-Jul-2000)
| rse@edv2:/u/rse/work/pth/src
| :> uname -a
| FreeBSD edv2.schoenbrunn.de 4.1-STABLE FreeBSD 4.1-STABLE #0: Thu Aug 17
| 11:04:29 CEST 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EDV2
| i386
| rse@edv2:/u/rse/work/pth/src
| :> cc `/tmp/pth/bin/pth-config --cflags` -o test test.c
| `/tmp/pth/bin/pth-config --ldflags --libs`
| rse@edv2:/u/rse/work/pth/src
| :> ./test
| libc usleep
| Time elapsed: 2.011649 sec
| Time elapsed: 2.017588 sec
| pth_usleep
| Time elapsed: 2.007629 sec
| Time elapsed: 2.017582 sec
| Time elapsed: 2.017669 sec
| rse@edv2:/u/rse/work/pth/src
| :>
And as you can see, it works fine. The same with Pth 1.4a3. So, unless I can
reproduce the problem I cannot fix it, of course. Can you confirm that it
still happens for you? Perhaps you've built Pth differently? Which configure
parameters have you used and which compiler?
> Running pth_usleep in a thread in doesn't break the scheduler but it
> returns almost immediately (I have not measured) regardless of what
> value is sent to pth_usleep.
You mean you see a difference between the (implicit) main thread and an
(explicitly) spawned thread, right? Hmmm... beside the different stack (main
uses the auto-growing process stack while the spawned threads use fixed-size
malloc'ed stacks), there should be no difference - at least not from the
schedulers point of view.
> I use the following workaround:
>
> ptt = pth_time(sleep_time / 1000000, sleep_time % 1000000);
> pth_nap(ptt)
But this is internally 100% equivalent to calling pth_usleep(),
because if you look at pth_usleep()'s implementation in pth_high.c:
| /* calculate asleep time */
| offset = pth_time((long)(usec / 1000000), (long)(usec % 1000000));
| pth_time_set(&until, PTH_TIME_NOW);
| pth_time_add(&until, &offset);
|
| /* and let thread sleep until this time is elapsed */
| ev = pth_event(PTH_EVENT_TIME|PTH_MODE_STATIC, &ev_key, until);
| pth_wait(ev);
and the one for pth_nap() from pth_lib.c (naptime is your ptt):
| pth_time_set(&until, PTH_TIME_NOW);
| pth_time_add(&until, &naptime);
| ev = pth_event(PTH_EVENT_TIME|PTH_MODE_STATIC, &ev_key, until);
| pth_wait(ev);
So, your workaround should either work or fail the same way
as pth_sleep() and pth_usleep(). I'm confused...
> if I want the program to sleep sleep_time usecs. As I explained above
> the following doesn't work if sleep_time >= 2000080:
>
> ptt = pth_time(0, sleep_time);
> pth_nap(ptt)
And this is my second problem: First there is no such magic value like 2000080
in Pth and second I was not able to reproduce this with neither Pth 1.3.7 nor
1.4a3 under a FreeBSD 4.1-STABLE box. Please give more details to allow me to
reproduce the problem.
Yours,
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]
