GFile allows for the possibility that external implementations may not
support thread-default contexts yet, via
g_file_supports_thread_contexts(). GVolumeMonitor is not yet
thread-default-context aware.
Add a test program to verify that basic gio async ops work correctly
in non-default contexts.
http://bugzilla.gnome.org/show_bug.cgi?id=579984
Currently, to implement cancellability correctly, all synchronous
calls to GSocket must be preceded by a g_socket_condition_wait() call,
(even though GSocket does this internally as well) and all
asynchronous calls must do occasional manual
g_cancellable_is_cancelled() checks. Since it's trivial to do these
checks inside GSocket instead, and we don't particularly want to
encourage people to use the APIs non-cancellably, move the
cancellation support into GSocket and simplify the existing callers.
http://bugzilla.gnome.org/show_bug.cgi?id=586797
This patch and the previous ones fixes the performance issues noted in
Bug 587089 – lookup_attribute() takes too much CPU
It increases performance for querying attributes by ~15% in my tests.
g_filename_complete_get_completions() return value is meant to be a
g_strfreev-compatible array i.e. NULL-terminated. However, pointer arrays
aren't automagically NULL-terminated. This fixes bug 586868
I'm not sure why we used the elaborate formula to convert the io-priority
to the priority of the mainloop idle when emulating async i/o with idles.
However, it causes the default io priority to be less than the normal
idle prio, so the i/o won't be scheduled if there is an idle outstanding.
There is really no great mapping to use here, doing blocking i/o in an
idle of any prio is generally bad and apps doing a lot of async i/o should
initialize threads. However, if we use the io-priority directly we at least
avoid the starvation problem above and make things easier to understand.
Add API for starting/stopping drives. This new API will enable
GVolumeMonitor and GVfs implementations to add support for the
following features
1. Powering down external hard disk enclosures / drives
2. Starting/stopping multi-disk devices (such as RAID/btrfs/ZFS)
3. Connecting/disconnecting iSCSI devices
4. Reacting to the user pressing e.g. the "remove drive" button on
a IBM/Lenovo Ultrabay: http://www.thinkwiki.org/wiki/Ultrabay
See the bug for the corresponding GVfs and Nautilus changes.
The icon names are folder-documents, folder-download, folder-music,
folder-pictures, folder-publicshare, folder-templates, folder-videos.
See bug 541276.
Change the logic in g_socket_listener_add_inet_port() as per the
reasoning in the bug report.
- If the OS supports neither IPv6 or IPv4, fail.
- If the OS supports only IPv6, do that.
- If the OS supports only IPv4, do that.
- If the OS supports IPv6 and IPv6 "speaks" IPv4 then bind it
and be done.
- If the OS supports IPv6 and IPv6 doesn't "speak" IPv4 then
create an additional socket for IPv4.
- If binding any socket fails then fail the entire call.
Also, remove the ability to call this function with port == 0. This
is a useless thing to do anyway since you have no way to know what
port number was actually allocated. We should have a separate
function to deal with this.
... as g_cancellable_cancel()
Rework a g_critical() that would (rarely) trigger when _reset() was
called in a thread different from _cancel() by making _reset() wait for
the cancel function to be finished the same way
g_cancellable_disconnect() uses.
The default implementation of g_file_copy() checked the size of the file
to copy to give useful progress updates unconditionally. This can cause
long delays on 1-connection FTP servers while it tries to open a second
connection before it returns EBUSY. This patch makes this query only
happen when we actually send progress updates.
In particular, targets with weight 0 should be very UNlikely to be
selected, not very likely, as they were before. However, even ignoring
that bug in the logic, there was an additional bug (swapping list
items would cause the 0-weight items to get re-ordered incorrectly
anyway), and the code contained several fencepost errors.
This patch also adds gio/tests/srvtarget.c, which confirms that for a
sample list of targets, we now generate all possible correct random
sortings and no incorrect sortings, and the correct sortings occur in
roughly the expected proportions (though if the current code is
still wrong, those proportions may be wrong as well).
http://bugzilla.gnome.org/show_bug.cgi?id=583398
Do proper referencing and unreferencing of
GWinHttpFileInputStream::file and
GWinHttpFileInputStream::file::vfs. Implement
GWinHttpFileInputStream::close_fn.
The docs mentions a separate seekable API for the various file streams
which don't actually exists. Change this to refer to the generic
GSeekable calls.
It was possible for a signal handler to remove the last reference and
dispose the monitor. If there were remaining pending_file_changes they
tried to dereference the disposed monitor.
This patch simply calls g_object_{ref,unref} around the loop that signals
the changes.
It's a bit lame, but some of our C++ wrapping scripts expect objects to be
typedefed like:
typedef struct _FooClass FooClass;
struct {} _FooClass;
Rather than:
typedef struct {} FooClass;
Functionally they're the same, but the former makes our lives easier in the
short term
The whole protocol name thing is pretty weird. The getprotobyname functions
seem to only specify one mapping for name <-> ids, so all families/types
must use the same values. Plus the values used for the protocols are
standardized by IANA, so are always the same.
So, we drop using names for protocols, intead introducing an enum with
a few commonly availible and used protocols.
