why does ObjectInputStream constructor block reading a header

[kartik]

The ObjectInputStream constructor blocks till it reads a header from
the underlying input stream. This can cause deadlocks when you have a
pair of object streams communicating over sockets (it has happened to
me). Does anybody know why it may have been coded this way instead of
reading the header on the first call to readObject()?

-kartik

 

[Esmond Pitt]

The ObjectInputStream constructor blocks till it reads a header from
the underlying input stream. This can cause deadlocks when you have a
pair of object streams communicating over sockets (it has happened to
me). Does anybody know why it may have been coded this way instead of
reading the header on the first call to readObject()?

No but you can avoid the deadlock by creating the ObjectOutputStream
first and flushing it, then creating the ObjectInputStream.

 

[Tony Morris]

The ObjectInputStream constructor blocks till it reads a header from
the underlying input stream. This can cause deadlocks when you have a
pair of object streams communicating over sockets (it has happened to
me). Does anybody know why it may have been coded this way instead of
reading the header on the first call to readObject()?

-kartik

Yes - they have been written in accordance with specification and the
specification is the correct way of solving the problem.

The problem you have is attempting asynchronous I/O in the same thread.
This is just not possible.

 

[Esmond Pitt]

In that case, you want to look at the java.nio package.

Why?

 

[Tony Morris]

Why?

Because it includes non-blocking I/O.
http://java.sun.com/j2se/1.5.0/docs...ctableChannel.html#configureBlocking(boolean)

 

[Esmond Pitt]

Because it includes non-blocking I/O.
http://java.sun.com/j2se/1.5.0/docs...ctableChannel.html#configureBlocking(boolean)

I'm sorry, I knew that, I was unclear: what I meant was why does the OP
need non-blocking I/O? It was only an order of initialization problem.

 

[kartik]

Because it includes non-blocking I/O.

But I do *not* want non-blocking I/O (and its associated complexity).
My only problem is that the ObjectInputStream constructor reads the
stream header before it really has to, and that's causing deadlock.

 

[Tony Morris]

But I do *not* want non-blocking I/O (and its associated complexity).

My only problem is that the ObjectInputStream constructor reads the
stream header before it really has to, and that's causing deadlock.

It doesn't cause deadlock.
Perhaps you meant a blocked I/O operation?
I'm not sure if that particular constructor does block, but it's no secret
that J2SE I/O has flaws, and that this is one of them (the inability to
cleanly break out of a blocked I/O state).
In most cases, even an interrupt fails.

There are texts on the topic.
I suggest "Taming Java Threads", Allen Holub.
There's another good one my Doug Lea (forget the title).

 

[Esmond Pitt]

It doesn't cause deadlock.

It does cause deadlock, between the peers, unless one of them constructs
the ObjectOutputStream first. Try it yourself.

Perhaps you meant a blocked I/O operation?

No he doesn't.

I'm not sure if that particular constructor does block

I am sure that that particular constructor does block until it receives
the stream header from the corresponding ObjectOutputStream()
constructor at the peer.

, but it's no secret
that J2SE I/O has flaws, and that this is one of them (the inability to
cleanly break out of a blocked I/O state).

'This' is not what the OP is talking about.

In most cases, even an interrupt fails.

There are texts on the topic.
I suggest "Taming Java Threads", Allen Holub.
There's another good one my Doug Lea (forget the title).

Tony, this is all irrelevant.

 

[kartik]

It doesn't cause deadlock.
Perhaps you meant a blocked I/O operation?

I meant a deadlock. I have two machines that communicate using object
streams over sockets. Each tries to create the ObjectInputStream
before the ObjectOutputStream, but since the other side hasn't written
the stream header (because it hasn't constructed its output stream),
they deadlock.

I'm not sure if that particular constructor does block

It does. See http://java.sun.com/j2se/1.5.0/docs...m.html#ObjectInputStream(java.io.InputStream)

There are texts on the topic.
I suggest "Taming Java Threads", Allen Holub.
There's another good one my Doug Lea (forget the title).

Concurrent Programming in Java?