[dougr 28-Aug-97] I am running:

java -fullversion
java full version "jvm111_23n:97.06.09"

Currently there is no poll() equivalent in the
Java-net (or/and IO) classes.

I am developing the Java version of the rpc.cmsd. One of the goals
is 10,000 connections. Estimate FCS in Mar-98.

However, without a poll like feature in the Java classes, I have
to create one thread for each connection. Then in each thread
block in a read system call. This limis to to less than 2,000
connections.

Or I have to snag some of the Socket source code, grab
the socket() fd, and do the poll with a native method.

There are performance problems with one thread per connection
and blocking reads:

  Measured results on a dual-50mhz SS10 64MB:

  1) Java native threads, no poll:

    Almost 7000-8000 Sockets can be open if they do *nothing* at all.
   OR
    About 2000 Sockets can be in a blocking read() call.

    At which point the OS is swaping so much it takes an L1-A to get out.

  2) With a 'C' program and poll() (select is limited to 1024 fd's):

    10,000 Sockets can be open.
   AND
    10,000 Sockets can be in poll() waiting for data.

    and the system is still usable.

  3) With a 'C' program and NOT using poll()

    10,000 Sockets can be open
   AND
    Almost 2,000 Sockets can be in a blocking read() call, then
    the program exits with a error indication that there was no
    more resources (I forgot the exact errno).


Also,
With HTTP 1.1(?) and connections that stay alive, I would think that
the Java-Web-Server will be running into the same problem.


 1998-01-21 ###@###.###

Request from Ed Randall ###@###.### is to add the KEEPALIVE
timeout notifications to this event/listenr mechanism.


Name: mc57594 Date: 01/12/2000


J:\borsotti\jtest>java -version
java version "1.2"
Classic VM (build JDK-1.2-V, native threads)
Consider the following program:

import java.io.*;
public class Th {
    static Thread killer;
    static Thread waster;

    class Killer extends Thread {
        public void run() {
            System.out.println("killer running");
            try {
                sleep(3000);
                System.out.println("killer interrupts waster" +
                    waster.isInterrupted());
                waster.interrupt();
                System.out.println("killer has interrupted waster" +
                    waster.isInterrupted());
            } catch (InterruptedException e) {
                System.out.println("killer interrupted! " + isInterrupted());
            }
            System.out.println("killer DONE!");
        }
    }
    class Waster extends Thread {
        public void run() {
            System.out.println("waster running");
            try {
                FileOutputStream f = new FileOutputStream("tmp.tmp");
                byte[] ba = new byte[10000000];
                f.write(ba);
            } catch (IOException e) {
                System.out.println("waster ioexception!" + isInterrupted());
            }
            System.out.println("waster DONE!");
        }
    }

    public static void main (String[] args) {
        Th t = new Th();
        killer = t.new Killer();
        waster = t.new Waster();
        waster.start();
        killer.start();
    }
}


when executed it prints:

J:\borsotti\jtest>java Th
waster running
killer running
killer interrupts wasterfalse
killer has interrupted wastertrue
killer DONE!
^C

J:\borsotti\jtest>dir tmp.tmp
 Volume in drive J is \\tlvhgr\dknmpm3
 Volume Serial Number is 0000-0000

 Directory of J:\borsotti\jtest

12/07/99 04:16p 10,000,000 tmp.tmp
               1 File(s) 10,000,000 bytes

in this run, the program has been activated, the
"waster" thread started to write a long file, the
"killer" thread tried to kill it without success,
and the control-C took effect only at the end of
the execution (as shown by the file size).

Apparently, the write() methods is not aborted as
a result of interrupting the executing thread.
A similar test, in which write() was replaced by
read() shows the same behaviour.

This makes impossible to implement applications in
which some control (e.g. a "stop" button) is provided
to allow the user to abort a long i/o operation which
was wrongly started
========================
From: Angelo Borsotti <###@###.###>
To: ###@###.###
Subject: Re: (Review ID: 98744) Incomplete handling of i/o interruption.

Hello Mark,

in my example program, the killer in indeed making
a waster.interrupt(). I.e. it is interrupting a
thread, which is making an io operation.
The purpose, and the meaning of "interruption" has
always been in most system that of making a thread
(process or whatever independently running activity)
which was blocked in some long operation to be
awakened to complete it.
The method sleep() implements it correctly: it stop
sleeping.
Note that ideally, there would be no need for the
concept of interruption if all threads never get blocked
for long time: instead of it they could a sequence of
smaller operation and test in between a flag which could
be set by other threads to interrupt them.
Even a sleep() can be broken in smaller sleep()'s.
This, however, besides being inefficient, it makes also
programs more complex, and is by no means a safe solution
since nobody prevents a thread to make a long operation.
Without interruptions, you have no way to stop a program
which is flooding your terminal with output you no longer
want to see, and that by chance has been written by a
programmer who did not know that interruptions did not
behave as commonly expected.

I thus should reinforce my request to have interruptions behave
as they should be.

Best Regards

Angelo Borsotti.
(Review ID: 98744)
======================================================================