luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-11-06 17:36:14 +01:00
Code Issues Packages Projects Releases Wiki Activity
e4a2aa8f39
glib/gio/gioprivate.h

65 lines
2.3 KiB
C
Raw Normal View History

GInputStream: Add g_input_stream_async_read_is_via_threads() In implementing a better g_output_stream_splice_async() and possibly other situtations it's helpful to know whether the input stream's read function internally uses threads. If it and the output stream's write async functions use threads, then the splice function could spawn a single thread for better efficiency. This patch adds a function to determine whether an input stream's g_input_stream_read_async() function internally uses threads. https://bugzilla.gnome.org/show_bug.cgi?id=691581
2013-02-24 00:32:31 +01:00
/* GIO - GLib Input, Output and Streaming Library
*
* Copyright (C) 2013 Collabora Ltd.
*
gio: Add SPDX license headers automatically Add SPDX license (but not copyright) headers to all files which follow a certain pattern in their existing non-machine-readable header comment. This commit was entirely generated using the command: ``` git ls-files gio/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs' ``` Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Helps: #1415
2022-05-18 10:12:45 +02:00
* SPDX-License-Identifier: LGPL-2.1-or-later
*
GInputStream: Add g_input_stream_async_read_is_via_threads() In implementing a better g_output_stream_splice_async() and possibly other situtations it's helpful to know whether the input stream's read function internally uses threads. If it and the output stream's write async functions use threads, then the splice function could spawn a single thread for better efficiency. This patch adds a function to determine whether an input stream's g_input_stream_read_async() function internally uses threads. https://bugzilla.gnome.org/show_bug.cgi?id=691581
2013-02-24 00:32:31 +01:00
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
gio/: LGPLv2+ -> LGPLv2.1+ Sub-directories inside gio/ already processed in a previous commit: - fam/ - gdbus-2.0/ (which contains only codegen/) - gvdb/ - inotify/ - tests/ - win32/ - xdgmime/ Other sub-directories inside gio/: - completion/: no license headers - kqueue/: not LGPL, BSD-style license https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-27 18:21:30 +02:00
* version 2.1 of the License, or (at your option) any later version.
GInputStream: Add g_input_stream_async_read_is_via_threads() In implementing a better g_output_stream_splice_async() and possibly other situtations it's helpful to know whether the input stream's read function internally uses threads. If it and the output stream's write async functions use threads, then the splice function could spawn a single thread for better efficiency. This patch adds a function to determine whether an input stream's g_input_stream_read_async() function internally uses threads. https://bugzilla.gnome.org/show_bug.cgi?id=691581
2013-02-24 00:32:31 +01:00
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General
Updated FSF's address
2014-01-23 12:58:29 +01:00
* Public License along with this library; if not, see <http://www.gnu.org/licenses/>.
GInputStream: Add g_input_stream_async_read_is_via_threads() In implementing a better g_output_stream_splice_async() and possibly other situtations it's helpful to know whether the input stream's read function internally uses threads. If it and the output stream's write async functions use threads, then the splice function could spawn a single thread for better efficiency. This patch adds a function to determine whether an input stream's g_input_stream_read_async() function internally uses threads. https://bugzilla.gnome.org/show_bug.cgi?id=691581
2013-02-24 00:32:31 +01:00
*/
#ifndef __G_IO_PRIVATE_H__
#define __G_IO_PRIVATE_H__
#include "ginputstream.h"
GOutputStream: Add g_output_stream_async_write_is_via_threads() In implementing a better g_output_stream_splice_async() and possibly other situtations it's helpful to know whether the output stream's write function internally uses threads. If it and the input stream's read async functions use threads, then the splice function could spawn a single thread for better efficiency. This patch adds a function to determine whether an output stream's g_output_stream_write_async() function internally uses threads. https://bugzilla.gnome.org/show_bug.cgi?id=691581
2013-02-24 00:42:49 +01:00
#include "goutputstream.h"
GSocketClient: For _CONNECTING event, make remote address accessible My application (hotssh) would like to get the resolved address from DNS, before we start the connect(). We could add a new event, but it's easy enough to just cache it on the GSocketConnection; this avoids any new API. https://bugzilla.gnome.org/show_bug.cgi?id=712547
2013-11-18 22:15:34 +01:00
#include "gsocketconnection.h"
#include "gsocketaddress.h"
GInputStream: Add g_input_stream_async_read_is_via_threads() In implementing a better g_output_stream_splice_async() and possibly other situtations it's helpful to know whether the input stream's read function internally uses threads. If it and the output stream's write async functions use threads, then the splice function could spawn a single thread for better efficiency. This patch adds a function to determine whether an input stream's g_input_stream_read_async() function internally uses threads. https://bugzilla.gnome.org/show_bug.cgi?id=691581
2013-02-24 00:32:31 +01:00
G_BEGIN_DECLS
gboolean g_input_stream_async_read_is_via_threads (GInputStream *stream);
streams: add private 'async close via threads' API Add an internal helper to find out if close_async() is implemented via threads using the default implementation in the base class. We will use this to decide if we should do a 'pure async' close of a GIOStream or not. https://bugzilla.gnome.org/show_bug.cgi?id=741630
2015-01-20 14:09:33 +01:00
gboolean g_input_stream_async_close_is_via_threads (GInputStream *stream);
GOutputStream: Add g_output_stream_async_write_is_via_threads() In implementing a better g_output_stream_splice_async() and possibly other situtations it's helpful to know whether the output stream's write function internally uses threads. If it and the input stream's read async functions use threads, then the splice function could spawn a single thread for better efficiency. This patch adds a function to determine whether an output stream's g_output_stream_write_async() function internally uses threads. https://bugzilla.gnome.org/show_bug.cgi?id=691581
2013-02-24 00:42:49 +01:00
gboolean g_output_stream_async_write_is_via_threads (GOutputStream *stream);
Add writev() / writev_all() API to GOutputStream and GPollableOutputStream This comes with default implementations around the normal write functions and async variants. Fixes https://gitlab.gnome.org/GNOME/glib/issues/1431
2018-09-13 12:10:36 +02:00
gboolean g_output_stream_async_writev_is_via_threads (GOutputStream *stream);
streams: add private 'async close via threads' API Add an internal helper to find out if close_async() is implemented via threads using the default implementation in the base class. We will use this to decide if we should do a 'pure async' close of a GIOStream or not. https://bugzilla.gnome.org/show_bug.cgi?id=741630
2015-01-20 14:09:33 +01:00
gboolean g_output_stream_async_close_is_via_threads (GOutputStream *stream);
GInputStream: Add g_input_stream_async_read_is_via_threads() In implementing a better g_output_stream_splice_async() and possibly other situtations it's helpful to know whether the input stream's read function internally uses threads. If it and the output stream's write async functions use threads, then the splice function could spawn a single thread for better efficiency. This patch adds a function to determine whether an input stream's g_input_stream_read_async() function internally uses threads. https://bugzilla.gnome.org/show_bug.cgi?id=691581
2013-02-24 00:32:31 +01:00
GSocketClient: For _CONNECTING event, make remote address accessible My application (hotssh) would like to get the resolved address from DNS, before we start the connect(). We could add a new event, but it's easy enough to just cache it on the GSocketConnection; this avoids any new API. https://bugzilla.gnome.org/show_bug.cgi?id=712547
2013-11-18 22:15:34 +01:00
void g_socket_connection_set_cached_remote_address (GSocketConnection *connection,
GSocketAddress *address);
Clamp number of vectors to IOV_MAX / UIO_MAXIOV for GOutputStream writev() calls in the implementations More vectors will give an error and we can simply clamp here and consider it like a short write instead. In case of GSocketOutputStream this is done here instead of inside GSocket before calling sendmsg() because we we can't generically handle short writes when sending messages on a socket, e.g. for datagram sockets this causes only part of the datagram to be sent and an error would be more useful in this case than sending corrupted data. Also reduce the fallback limit to 16 in gsocket.c as that's the minimum value required by POSIX and add a static assertion that the limit is never bigger than G_MAXINT as that's the type recvmmsg/sendmmsg take.
2019-05-29 15:04:55 +02:00
/* POSIX defines IOV_MAX/UIO_MAXIOV as the maximum number of iovecs that can
* be sent in one go. We define our own version of it here as there are two
* possible names, and also define a fall-back value if none of the constants
* are defined */
#if defined(IOV_MAX)
#define G_IOV_MAX IOV_MAX
#elif defined(UIO_MAXIOV)
#define G_IOV_MAX UIO_MAXIOV
Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments" This reverts commit 476e33c3f3632bd32370fadc67b10d61da9a4098. We’ve decided to remove `G_OS_DARWIN` in favour of recommending people use `__APPLE__` instead. As per the discussion on #2802 and linked issues, * Adding a new define shifts the complexity from “which of these platform-provided defines do I use” to “which platform-provided defines does G_OS_DARWIN use” * There should ideally be no cases where a user of GLib has to use their own platform-specific code, since GLib should be providing appropriate abstractions * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS and iOS) hides the complexity of what the user is actually testing: are they testing for the Mach kernel, the Carbon and/or Cocoa user space toolkits, macOS vs iOS vs tvOS, etc Helps: #2802
2022-11-02 11:01:09 +01:00
#elif defined(__APPLE__)
Define G_IOV_MAX to 512 on macOS/iOS For macOS/iOS, UIO_MAXIOV is documented in writev(2), but <sys/uio.h> only declares it if defined(KERNEL) Inspired by a GStreamer MR by Jim Mason https://gitlab.freedesktop.org/gstreamer/gstreamer/merge_requests/277
2019-09-07 18:42:00 +02:00
/* For macOS/iOS, UIO_MAXIOV is documented in writev(2), but <sys/uio.h>
* only declares it if defined(KERNEL) */
#define G_IOV_MAX 512
Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments" This reverts commit 476e33c3f3632bd32370fadc67b10d61da9a4098. We’ve decided to remove `G_OS_DARWIN` in favour of recommending people use `__APPLE__` instead. As per the discussion on #2802 and linked issues, * Adding a new define shifts the complexity from “which of these platform-provided defines do I use” to “which platform-provided defines does G_OS_DARWIN use” * There should ideally be no cases where a user of GLib has to use their own platform-specific code, since GLib should be providing appropriate abstractions * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS and iOS) hides the complexity of what the user is actually testing: are they testing for the Mach kernel, the Carbon and/or Cocoa user space toolkits, macOS vs iOS vs tvOS, etc Helps: #2802
2022-11-02 11:01:09 +01:00
#else
Clamp number of vectors to IOV_MAX / UIO_MAXIOV for GOutputStream writev() calls in the implementations More vectors will give an error and we can simply clamp here and consider it like a short write instead. In case of GSocketOutputStream this is done here instead of inside GSocket before calling sendmsg() because we we can't generically handle short writes when sending messages on a socket, e.g. for datagram sockets this causes only part of the datagram to be sent and an error would be more useful in this case than sending corrupted data. Also reduce the fallback limit to 16 in gsocket.c as that's the minimum value required by POSIX and add a static assertion that the limit is never bigger than G_MAXINT as that's the type recvmmsg/sendmmsg take.
2019-05-29 15:04:55 +02:00
/* 16 is the minimum value required by POSIX */
#define G_IOV_MAX 16
#endif
/* The various functions taking iovecs as parameter use a plain int
* for the number of vectors. Limit it to G_MAXINT for this reason.
*/
G_STATIC_ASSERT (G_IOV_MAX <= G_MAXINT);
GSocketClient: For _CONNECTING event, make remote address accessible My application (hotssh) would like to get the resolved address from DNS, before we start the connect(). We could add a new event, but it's easy enough to just cache it on the GSocketConnection; this avoids any new API. https://bugzilla.gnome.org/show_bug.cgi?id=712547
2013-11-18 22:15:34 +01:00
GInputStream: Add g_input_stream_async_read_is_via_threads() In implementing a better g_output_stream_splice_async() and possibly other situtations it's helpful to know whether the input stream's read function internally uses threads. If it and the output stream's write async functions use threads, then the splice function could spawn a single thread for better efficiency. This patch adds a function to determine whether an input stream's g_input_stream_read_async() function internally uses threads. https://bugzilla.gnome.org/show_bug.cgi?id=691581
2013-02-24 00:32:31 +01:00
G_END_DECLS
#endif /* __G_IO_PRIVATE__ */
Reference in New Issue Copy Permalink