Date: Thu, 29 Oct 1998 11:10:06 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: current@FreeBSD.ORG, eischen@vigrid.com, info@highwind.com, lists@tar.com Subject: Re: Thread Scheduler bug Message-ID: <199810291610.LAA11080@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
> > >It looks like setitimer isn't working as the threads library > >expects it to. The timer isn't going off, but it seems to be > >set properly. > > > >If you manually kill -VTALRM the running process, you'll see > >the markTimeThread run. > > > >I placed a print statement in the threads library where the > >timer is set, and it is being called with the proper values > >(100msec time slice). > > > >Why does heavy IO stop the timer from going off and the > >process from being signaled? > > Possibly the VTALRM timer measures only time spent in user mode > and not in kernel mode. This heavy I/O takes place almost entirely > in kernel mode and it is the only process running. Therefore, very > little user time is being accumulated. > > Possibly it you waited long enough, you'd still get the SIGVTALRM. > If you add some user mode processing to the thread, you'll see > the SIGVTALRM sooner. Yeah, I just figured this out (should pay closer attention to the man pages). Seems like the profiling timer would be closer to what we'd want (not to say the threads library should use the profiling timer). A quick hack to replace occurrences of SIGVTALRM with SIGPROF in the threads library seems to make the test program work more correctly. Perhaps SIGALRM should be used instead of SIGVTALRM? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810291610.LAA11080>