Date: Sat, 27 Nov 1999 14:39:08 -0800 From: Jake Burkholder <jburkhol@home.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: Julian Elischer <julian@whistle.com>, arch@freebsd.org Subject: Re: Threads stuff Message-ID: <19991127223909.22A511FCF@io.yi.org> In-Reply-To: Your message of "Sat, 27 Nov 1999 06:40:36 EST." <383FC334.F96FDAB1@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Julian Elischer wrote: > > > > ok well I'm only sketching out one solutionso don't feel that ai'm > > bullying you into anything.. > > > > in this scheme however there is nothing to say that we can't keep track of > > time spent in IO. > > As long as the UTS was informed of the time spent in the kernel (I suppose > via the IO control block?) for each KSE, then that would probably be good > enough. I've put a diagram up on my web page that tries to incorporate some of these ideas. I haven't included the queue-ing, because that seems basically agreed upon. http://24.66.174.118/ Both a gif and the tgif obj file are there. I hope its not confusing. The arrows are meant trace the path that the scheduler and a thread making a blocking or non-blocking system call might take, and the ellipses are states I guess. I'm just going from what Daniel said about libc_r having to get the time of day and set the interval timer in order to do a context switch, which can probably be done in one system call. Either the context can be saved in userland, in which case the scheduler returns normally, and does a longjmp or the equivalent, or the thread could be resumed as part of the system call. Let me know what you think. thanks, Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991127223909.22A511FCF>