Why can I not use a selector on a FileChannel? I'd like to block until
data appears in the file. It looks like a SocketChannel supports
registering with a selector but not FileChannel.
Better yet, its too bad Java didn't implement FIFOs (named pipes) that
we get in UNIX C++.
-Robert
Roedy Green - 05 Nov 2005 08:44 GMT
>Why can I not use a selector on a FileChannel? I'd like to block until
>data appears in the file. It looks like a SocketChannel supports
>registering with a selector but not FileChannel.
>Better yet, its too bad Java didn't implement FIFOs (named pipes) that
>we get in UNIX C++.
Under what circumstances could data just appear in a file? Recall
that in many OSes, having an open file handle does not guarantee your
copy will know anything about what other jobs are doing.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Thomas Hawtin - 05 Nov 2005 09:02 GMT
> Under what circumstances could data just appear in a file? Recall
> that in many OSes, having an open file handle does not guarantee your
> copy will know anything about what other jobs are doing.
Generally data appearing in the FileChannel is associated with the disk
moving underneath the head. For NFS/SMB it's much the same as SocketChannel.
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/
Robert M. Gary - 06 Nov 2005 05:12 GMT
I guess I'm showing my UNIX background. In UNIX we have Fifo files,
which are just pipes that have names on disk and buffer on disk. It is
often very useful to pass data between processes using fifos because
the file system buffers the data if one process goes down. It means you
don't have to worry about missing data. I'm not aware of any persistant
IPC mechanisms in Java.
Roedy Green - 06 Nov 2005 08:19 GMT
>I guess I'm showing my UNIX background. In UNIX we have Fifo files,
>which are just pipes that have names on disk and buffer on disk. It is
>often very useful to pass data between processes using fifos because
>the file system buffers the data if one process goes down. It means you
>don't have to worry about missing data. I'm not aware of any persistant
>IPC mechanisms in Java.
in Java, both in nio and standard i/o, pipes are not treated the same
as files. Further they are not as powerful as they are in Unix since
you can't use them for communication between programs running in
separate address spaces.
The problem is, if Java had supported real pipes they would have had
to figure out a way to fake them on pipeless platforms.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Mark Thornton - 06 Nov 2005 09:15 GMT
> I guess I'm showing my UNIX background. In UNIX we have Fifo files,
> which are just pipes that have names on disk and buffer on disk. It is
> often very useful to pass data between processes using fifos because
> the file system buffers the data if one process goes down. It means you
> don't have to worry about missing data. I'm not aware of any persistant
> IPC mechanisms in Java.
While Windows NT has full support for Named Pipes, Windows 9x can only
connect to a named pipe on another (NT based) machine. On Windows, named
pipes used to the advantage over sockets that they could be secured, but
this can now be done with sockets as well. So named pipes are, I think,
now viewed as a legacy feature.
Mark Thornton
Mark Thornton - 05 Nov 2005 09:51 GMT
> Why can I not use a selector on a FileChannel? I'd like to block until
> data appears in the file. It looks like a SocketChannel supports
[quoted text clipped - 3 lines]
>
> -Robert
Probably considered a less valuable enhancement and thus of lower
priority than providing a solution for sockets. On some operating
systems I suspect it requires a different code path to the sockets case.
Windows 9x doesn't support this functionality at all.
Mark Thornton
Roedy Green - 06 Nov 2005 08:31 GMT
>Why can I not use a selector on a FileChannel?
If you look at which classes have a register method to let them use
Selector logic:
DatagramChannel, Pipe.SinkChannel, Pipe.SourceChannel,
ServerSocketChannel, SocketChannel
These are all ones that could wait a second or more for something to
happen. You don't want to tie up a thread (1 MB+ of RAM) that long
doing nothing.
In contrast, a FileChannel should satisfy its request within a few
milliseconds. It is most efficient just to let the thread itself wait
for the i/o.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Robert M. Gary - 07 Nov 2005 17:37 GMT
>In contrast, a FileChannel should satisfy its request within a few
> milliseconds. It is most efficient just to let the thread itself wait
> for the i/o.
Files could wait just as long as sockets. You don't know how long it
will take for some application to drop something in the file.
-Robert
Roedy Green - 06 Nov 2005 08:58 GMT
>Why can I not use a selector on a FileChannel?
I am working on a companion to the File I/O Amanuensis for nio. I
have not seen how you go about initiating two reads to a file on the
same thread then dealing with whichever completed first. Somewhere in
my deep past, perhaps PL/I, I could do this.
In nio, it looks like you still need two threads and block on both.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Matt Atterbury - 07 Nov 2005 02:44 GMT
> Why can I not use a selector on a FileChannel? I'd like to block until
> data appears in the file. It looks like a SocketChannel supports
> registering with a selector but not FileChannel.
> Better yet, its too bad Java didn't implement FIFOs (named pipes) that
> we get in UNIX C++.
IIRC POSIX does not support selecting on files. Since POSIX is
_probably_ the lowest common denominator that can be reasonably
assumed for a JVM, if it doesn't it support you can't have it.
m.
Thomas Hawtin - 07 Nov 2005 03:55 GMT
> IIRC POSIX does not support selecting on files. Since POSIX is
> _probably_ the lowest common denominator that can be reasonably
> assumed for a JVM, if it doesn't it support you can't have it.
Not really. It can easily be simulated. Alternatively, registering could
throw some not supported exception.
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/