From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,7d2c8b4487ef2145
X-Google-Attributes: gid103376,public
From: pontius@btv.ibm.com (Dale Pontius)
Subject: Re: Ada versus Java - Tasking
Date: 1997/01/20
Message-ID: <5bvt6v$sik@mdnews.btv.ibm.com>#1/1
X-Deja-AN: 211031330
references: <01bc03ee$594dc520$829d6482@joy.ericsson.se>
content-type: text/plain; charset=us-ascii
organization: IBM Microelectronics Division
mime-version: 1.0
newsgroups: comp.lang.ada
Date: 1997-01-20T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <1997Jan19.122511.1@eisner>,
        kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>
> Operating system developers have a much better chance to make the
> scheduling interact with the hardware properly, so I think the better
> choices are:
>
>       1) Rely on OS threading support, and wait for improvements.
>
>       2) Lobby the operating system provider for better support,
>          using all methods available, including examples of other
>          operating systems which do it better, either on the same
>          hardware or some other hardware.
>
        3) Adopt another thing from NT, fibers. Leave a thread to
           be defined as something that is scheduled by the kernel,
           but add a structure like NT fibers or user threads, that
           is scheduled in the user space. This doesn't, of course,
           drop pressure on the OS provider for making the very best
           thread switch possible.

Dale Pontius
(NOT speaking for IBM)