There is currently one bug in this area of green threads that we know about:
reading from standard input (System.in.read()) will indeed block all green
threads. The reason: green threads IO relies on making all fd's non-blocking,
and it seems that if the runtime exits while file descriptor 0 is O_NONBLOCK
the shell that exec'd the runtime dies (ugly). We're going to dork with this
for FCS still.
That one known bug pointed out: was this what you were referring to, or are
their *other* bugs you've seen where the runtime blocks? With a reproducible
test case perhaps?
-Dave Brown
> --randy
>
> On Wed, 22 Jan 1997, Robert Nicholson wrote:
>
> > Correct me if I'm wrong but won't it only block all thread of the same or
> > lesser priority? Higher priority threads still get a crack? Unlike
> > WIN32 where is will timeslice b/w threads of the same and lesser priority?
> >
> >
> > On Wed, 22 Jan 1997, Matt R. MacKinnon wrote:
> >
> > >
> > > It is my understanding that a when a thread blocks
> > > on I/O under Solaris, it blocks all threads, not
> > > just the thread doing the I/O (JDK 1.0.2).
> > >
> > > Can someone confirm this for me?
> > > If I'm correct, is there any work-around?
> > > Is this fixed in 1.1 ?
> > >
> > > Thanks,
> > > Matt
> > > --------------------------------------------
> > > Matthew R. MacKinnon matt@netsation.com
> > > Netsation Corp. http://www.netsation.com
> > > [ for list faq/archive/add/deletes see http://www.xcf.berkeley.edu/lists.html ]
> > >
> >
> > [ for list faq/archive/add/deletes see http://www.xcf.berkeley.edu/lists.html ]
> >
>
> [ for list faq/archive/add/deletes see http://www.xcf.berkeley.edu/lists.html ]
>
[ for list faq/archive/add/deletes see http://www.xcf.berkeley.edu/lists.html ]