c1b412f1 | 19-Jul-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: introduce a DNS resolver API
Currently DNS resolution is done automatically as part of the creation of a QIOChannelSocket object instance. This works ok for network clients where you just end up
io: introduce a DNS resolver API
Currently DNS resolution is done automatically as part of the creation of a QIOChannelSocket object instance. This works ok for network clients where you just end up a single network socket, but for servers, the results of DNS resolution may require creation of multiple sockets.
Introducing a DNS resolver API allows DNS resolution to be separated from the socket object creation. This will make it practical to create multiple QIOChannelSocket instances for servers.
Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
59de517d | 11-Aug-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: remove Error parameter from QIOTask thread worker
Now that task objects have a directly associated error, there's no need for an an Error **errp parameter to the QIOTask thread worker function.
io: remove Error parameter from QIOTask thread worker
Now that task objects have a directly associated error, there's no need for an an Error **errp parameter to the QIOTask thread worker function. It already has a QIOTask object, so can directly set the error on it.
Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
60e705c5 | 11-Aug-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: change the QIOTask callback signature
Currently the QIOTaskFunc signature takes an Object * for the source, and an Error * for any error. We also need to be able to provide a result pointer. Rat
io: change the QIOTask callback signature
Currently the QIOTaskFunc signature takes an Object * for the source, and an Error * for any error. We also need to be able to provide a result pointer. Rather than continue to add parameters to QIOTaskFunc, remove the existing ones and simply pass the QIOTask object instead. This has methods to access all the other data items required in the callback impl.
Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
1a447e4f | 11-Aug-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: add ability to associate an error with a task
Currently when a task fails, the error is never explicitly associated with the task object, it is just passed along through the completion callback.
io: add ability to associate an error with a task
Currently when a task fails, the error is never explicitly associated with the task object, it is just passed along through the completion callback. This adds the ability to explicitly associate an error with the task.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
52dd99e8 | 11-Aug-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: add ability to associate an opaque "result" with with a task
Currently there is no data associated with a successful task completion. This adds an opaque pointer to the task to store an arbitrar
io: add ability to associate an opaque "result" with with a task
Currently there is no data associated with a successful task completion. This adds an opaque pointer to the task to store an arbitrary result.
Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
20f4aa26 | 30-Sep-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: add ability to set a name for IO channels
The GSource object has ability to have a name, which is useful when debugging performance problems with the mainloop event callbacks that take too long.
io: add ability to set a name for IO channels
The GSource object has ability to have a name, which is useful when debugging performance problems with the mainloop event callbacks that take too long. By associating a name with a QIOChannel object, we can then set the name on any GSource associated with the channel.
Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
bf535208 | 26-Oct-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: set LISTEN flag explicitly for listen sockets
The SO_ACCEPTCONN ioctl is not portable across OS, with some BSD versions and OS-X not supporting it. There is no viable alternative to this, so ins
io: set LISTEN flag explicitly for listen sockets
The SO_ACCEPTCONN ioctl is not portable across OS, with some BSD versions and OS-X not supporting it. There is no viable alternative to this, so instead just set the feature explicitly when creating a listener socket.
The current users of qio_channel_socket_new_fd() won't ever be given a listening socket, so there's no problem with no auto-detecting it in this scenario
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
d8d3c7cc | 29-Sep-2016 |
Felipe Franciosi <felipe@nutanix.com> |
io: Introduce a qio_channel_set_feature() helper
Testing QIOChannel feature support can be done with a helper called qio_channel_has_feature(). Setting feature support, however, was done manually wi
io: Introduce a qio_channel_set_feature() helper
Testing QIOChannel feature support can be done with a helper called qio_channel_has_feature(). Setting feature support, however, was done manually with a logical OR. This patch introduces a new helper called qio_channel_set_feature() and makes use of it where applicable.
Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
e413ae0c | 29-Sep-2016 |
Felipe Franciosi <felipe@nutanix.com> |
io: Use qio_channel_has_feature() where applicable
Parts of the code have been testing QIOChannel features directly with a logical AND. This patch makes it all consistent by using the qio_channel_ha
io: Use qio_channel_has_feature() where applicable
Parts of the code have been testing QIOChannel features directly with a logical AND. This patch makes it all consistent by using the qio_channel_has_feature() function to test if a feature is present.
Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
74b6ce43 | 16-Jun-2016 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
socket: unlink unix socket on remove
qemu leaves unix socket files behind when removing a listening chardev or leaving. qemu could clean that up, even if doing so isn't race-free.
Fixes: https://bu
socket: unlink unix socket on remove
qemu leaves unix socket files behind when removing a listening chardev or leaving. qemu could clean that up, even if doing so isn't race-free.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1347077
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1466105332-10285-4-git-send-email-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
a5897205 | 07-Mar-2016 |
Paolo Bonzini <pbonzini@redhat.com> |
io: implement socket watch for win32 using WSAEventSelect+select
On Win32 we cannot directly poll on socket handles. Instead we create a Win32 event object and associate the socket handle with the e
io: implement socket watch for win32 using WSAEventSelect+select
On Win32 we cannot directly poll on socket handles. Instead we create a Win32 event object and associate the socket handle with the event. When the event signals readyness we then have to use select to determine which events are ready. Creating Win32 events is moderately heavyweight, so we don't want todo it every time we create a GSource, so this associates a single event with a QIOChannel.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
30fd3e27 | 10-Mar-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: remove checking of EWOULDBLOCK
Since we now canonicalize WSAEWOULDBLOCK into EAGAIN there is no longer any need to explicitly check EWOULDBLOCK for Win32.
Signed-off-by: Daniel P. Berrange <ber
io: remove checking of EWOULDBLOCK
Since we now canonicalize WSAEWOULDBLOCK into EAGAIN there is no longer any need to explicitly check EWOULDBLOCK for Win32.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|