Object Hierarchy:

Object hierarchy for IOStream


public abstract class IOStream : Object

GIOStream represents an object that has both read and write streams.

Generally the two streams act as separate input and output streams, but they share some common resources and state. For instance, for seekable streams, both streams may use the same position.

Examples of IOStream objects are SocketConnection, which represents a two-way network connection; and FileIOStream , which represents a file handle opened in read-write mode.

To do the actual reading and writing you need to get the substreams with get_input_stream and get_output_stream.

The IOStream object owns the input and the output streams, not the other way around, so keeping the substreams alive will not keep the IOStream object alive. If the IOStream object is freed it will be closed, thus closing the substreams, so even if the substreams stay alive they will always return g_io_error_closed for all operations.

To close a stream use close which will close the common stream object and also the individual substreams. You can also close the substreams themselves. In most cases this only marks the substream as closed, so further I/O on it fails but common state in the IOStream may still be open. However, some streams may support "half-closed" states where one direction of the stream is actually shut down.

Operations on IOStreams cannot be started while another operation on the IOStream or its substreams is in progress. Specifically, an application can read from the InputStream and write to the OutputStream simultaneously (either in separate threads, or as asynchronous operations in the same thread), but an application cannot start any IOStream operation while there is a IOStream, InputStream or OutputStream operation in progress, and an application can’t start any InputStream or OutputStream operation while there is a IOStream operation in progress.

This is a product of individual stream operations being associated with a given MainContext (the thread-default context at the time the operation was started), rather than entire streams being associated with a single MainContext.

GIO may run operations on IOStreams from other (worker) threads, and this may be exposed to application code in the behaviour of wrapper streams, such as BufferedInputStream or TlsConnection. With such wrapper APIs, application code may only run operations on the base (wrapped) stream when the wrapper stream is idle. Note that the semantics of such operations may not be well-defined due to the state the wrapper stream leaves the base stream in (though they are guaranteed not to crash).

Example: IOStream:

public static int main (string[] args) {
try {
// Create a file that can only be accessed by the current user:
File file = File.new_for_path ("my-test.bin");
IOStream ios = file.create_readwrite (FileCreateFlags.PRIVATE);

// Write data:

size_t bytes_written;
OutputStream os = ios.output_stream;
os.write_all ("My 1. line\n".data, out bytes_written);
os.write_all ("My 2. line\n".data, out bytes_written);

DataOutputStream dos = new DataOutputStream (os);
dos.put_string ("My 3. line\n");
dos.put_int16 (10);
ios = null;

// Open the file for reading:
InputStream @is = ();

// Read n bytes:

// Output: ``M``
uint8 buffer[1];
size_t size = (buffer);
stdout.write (buffer, size);

// Output: ``y 1. line``
DataInputStream dis = new DataInputStream (@is);
string str = dis.read_line ();
print ("%s\n", str);

// Output: ``My 2. line``
str = dis.read_line ();
print ("%s\n", str);

// Output: ``My 3. line``
str = dis.read_line ();
print ("%s\n", str);

// Output: ``10``
int16 i = dis.read_int16 ();
print ("%d\n", i);
} catch (Error e) {
print ("Error: %s\n", e.message);

return 0;

valac --pkg gio-2.0 GLib.IOStream.vala

Namespace: GLib
Package: gio-2.0



Creation methods:


Inherited Members: