Según la API de Java, laInputStream.read() se describe como:

Si no hay ningún byte disponible porque se ha alcanzado el final de la secuencia, se devuelve el valor -1. Este método bloquea hasta que los datos de entrada estén disponibles, se detecte el final de la secuencia o se produzca una excepción.

Tengo unwhile(true) loop haciendo una lectura y siempre obtengo -1 cuando no se envía nada por la transmisión. Eso es esperado.

Mi pregunta es ¿cuándo leería () alguna vez bloquear? Como si no obtiene ningún dato, devuelve -1. Esperaría que una lectura de bloqueo espere hasta que se reciban los datos. Si ha llegado al final de la secuencia de entrada, no debería leer () simplemente esperar los datos en lugar de devolver -1?

¿O leer () solo se bloquea si hay otro hilo que accede a la transmisión y su lectura () no puede acceder a la transmisión?

Lo que me lleva a mi siguiente pregunta. Solía tener un detector de eventos (proporcionado por mi biblioteca) que me notificaría cuando haya datos disponibles. Cuando me notificaran, llamaría awhile((aByte = read()) > -1) almacenar el byte. Estaba perplejo cuando recibía DOS eventos en una proximidad muy cercana y no se mostraban todos mis datos. Parecía que solo se mostraría el final de la cola de los datos del segundo evento y faltaba el resto.

Eventualmente cambié mi código para que cuando reciba un evento llame aif(inputStream.available() > 0) while((aByte = read()) > -1) almacenar el byte. Ahora funcionaba correctamente y se mostraban todos mis datos.

¿Alguien puede explicar este comportamiento? LosInputStream.available()e dice que @ devuelve el número de bytes que puede leer antes de bloquear la siguiente llamada (¿de la transmisión?). Incluso si no uso .available () esperaría que la lectura del primer evento simplemente bloquee la lectura del segundo evento, pero no borre o consuma demasiados datos de flujo. ¿Por qué hacer esto hace que no se muestren todos mis datos?