comp.lang.ada
 help / color / mirror / Atom feed
From: Darren New <dnew@san.rr.com>
Subject: Re: Multitasking theory question
Date: Wed, 26 Jun 2002 01:58:35 GMT
Date: 2002-06-26T01:58:35+00:00	[thread overview]
Message-ID: <3D191FE8.F6B9144A@san.rr.com> (raw)
In-Reply-To: MDSR8.151$7G4.17270@news.xtra.co.nz

AG wrote:
> 
> "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...

As I said once...

"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, no
amount of user-level coding in the run-time system is going to let you
schedule another thread to run during that time."

That's my position. Your position seems to be

"It's possible to write a non-blocking OS for any collection of hardware."

You see how these two statements are not in conflict?

Sure, it's possible to rewrite the blocking device drivers, given enough
time and programming competence. It also fails spectacularly when the user
unplugs the 10baseT connection and plugs in the new USB-based wireless
networking device released five years after you sold him your program.

> > 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.

Err, we were talking about Ada run-time systems doing multi-tasking under a
non-tasking and potentially non-reentrant OS, weren't we? I have no idea
what 'case' you think you're resting. I also think I don't care, since I
figured out that what you're talking about and what I'm talking about are
two different situations.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.



      reply	other threads:[~2002-06-26  1:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-20 20:46 Multitasking theory question Kai Schuelke
2002-06-20 20:53 ` Stephen Leake
2002-06-21  2:13 ` Ted Dennison
2002-06-24  3:18   ` AG
2002-06-24  4:13     ` tmoran
2002-06-24  4:24       ` AG
2002-06-24  7:33         ` Dale Stanbrough
2002-06-25  3:27           ` AG
2002-06-25  4:48             ` tmoran
2002-06-25  5:00               ` AG
2002-06-25  5:17               ` Darren New
2002-06-25  5:25                 ` AG
2002-06-24  5:43     ` Mark Biggar
2002-06-24  6:48       ` AG
2002-06-24 15:14         ` Darren New
2002-06-24 16:19           ` Larry Kilgallen
2002-06-25  2:01           ` AG
2002-06-25  3:21             ` Darren New
2002-06-25  4:01               ` AG
2002-06-25  4:19                 ` Darren New
2002-06-25  4:51                   ` AG
2002-06-26  1:58                     ` Darren New [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox