Re: Multitasking theory question

["AG" <ang@xtra.co.nz>]

"Darren New" <dnew@san.rr.com> wrote in message
news:3D17EF7D.40F88B17@san.rr.com...

> Err, well, no. I think you're still missing the point. Say you're trying
to
> write (say) a web server. The only I/O the OS supports is blocking I/O.
> There's no way to say "I have three sockets open, wait for whichever one
is
> readable first."

Do you have access to the timer interrupt? Can you switch into the Kernel
mode? (Hose the thing in the process perhaps, but can you?) Can you
intercept
PowerChute interrupts? If yes to all of the above, then what's the problem?
If not, ask your system administrator I guess.

>  The only way to make this work is either rewrite the
> blocking device drivers yourself

Yep, and we're back to where we started - you *can* re-write them if you
want to...

> Of course if you don't use any blocking calls in the OS
> then you can write your own scheduler.

Just where I joined this thread, thanks for confirming.

>
> Is it me, or do many of these discussions degenerate into "well, in spite
of
> the fact that what you're trying to say is obvious, here's one possible
way
> to read your words such that you'd be mistaken in a small number of
special
> cases"?

From another side of the fence, I fully agree - they do ;)

> If there are OS services you rely on that might possibly take an
> unacceptably long time to return to the control of the user program

For example, who's talking about "returning control"? Even in blocking calls
it is not really neccessary for a call to "return". Use an asynch trap and
just
abort it.

> amount of user-level coding in the run-time system is going to let you
> schedule another thread to run during that time.

Sorry? Did you just say "user-level coding in the run-time system"?
Guess I rest my case.