RepoMirrors
/
musl
mirror of git://git.musl-libc.org/musl
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
musl/include/aio.h

70 lines
1.4 KiB
C
Raw Normal View History

implement POSIX asynchronous io some features are not yet supported, and only minimal testing has been performed. should be considered experimental at this point.
2011-09-09 05:07:38 +00:00
#ifndef _AIO_H
#define _AIO_H
#ifdef __cplusplus
extern "C" {
#endif
default features: make musl usable without feature test macros the old behavior of exposing nothing except plain ISO C can be obtained by defining __STRICT_ANSI__ or using a compiler option (such as -std=c99) that predefines it. the new default featureset is POSIX with XSI plus _BSD_SOURCE. any explicit feature test macros will inhibit the default. installation docs have also been updated to reflect this change.
2012-09-08 03:13:55 +00:00
#include <features.h>
implement POSIX asynchronous io some features are not yet supported, and only minimal testing has been performed. should be considered experimental at this point.
2011-09-09 05:07:38 +00:00
#include <signal.h>
#include <time.h>
#define __NEED_ssize_t
#define __NEED_off_t
#include <bits/alltypes.h>
struct aiocb {
stupid typo (caused by rather ugly spelling in POSIX..) in aio
2011-09-28 15:36:11 +00:00
int aio_fildes, aio_lio_opcode, aio_reqprio;
implement POSIX asynchronous io some features are not yet supported, and only minimal testing has been performed. should be considered experimental at this point.
2011-09-09 05:07:38 +00:00
volatile void *aio_buf;
size_t aio_nbytes;
struct sigevent aio_sigevent;
void *__td;
int __lock[2];
make all objects used with atomic operations volatile the memory model we use internally for atomics permits plain loads of values which may be subject to concurrent modification without requiring that a special load function be used. since a compiler is free to make transformations that alter the number of loads or the way in which loads are performed, the compiler is theoretically free to break this usage. the most obvious concern is with atomic cas constructs: something of the form tmp=*p;a_cas(p,tmp,f(tmp)); could be transformed to a_cas(p,*p,f(*p)); where the latter is intended to show multiple loads of *p whose resulting values might fail to be equal; this would break the atomicity of the whole operation. but even more fundamental breakage is possible. with the changes being made now, objects that may be modified by atomics are modeled as volatile, and the atomic operations performed on them by other threads are modeled as asynchronous stores by hardware which happens to be acting on the request of another thread. such modeling of course does not itself address memory synchronization between cores/cpus, but that aspect was already handled. this all seems less than ideal, but it's the best we can do without mandating a C11 compiler and using the C11 model for atomics. in the case of pthread_once_t, the ABI type of the underlying object is not volatile-qualified. so we are assuming that accessing the object through a volatile-qualified lvalue via casts yields volatile access semantics. the language of the C standard is somewhat unclear on this matter, but this is an assumption the linux kernel also makes, and seems to be the correct interpretation of the standard.
2015-03-04 03:50:02 +00:00
volatile int __err;
implement POSIX asynchronous io some features are not yet supported, and only minimal testing has been performed. should be considered experimental at this point.
2011-09-09 05:07:38 +00:00
ssize_t __ret;
off_t aio_offset;
void *__next, *__prev;
char __dummy4[32-2*sizeof(void *)];
};
#define AIO_CANCELED 0
#define AIO_NOTCANCELED 1
#define AIO_ALLDONE 2
#define LIO_READ 0
#define LIO_WRITE 1
#define LIO_NOP 2
#define LIO_WAIT 0
#define LIO_NOWAIT 1
fix return types for aio_read and aio_write again previous fix was backwards and propagated the wrong type rather than the right one...
2011-09-14 01:21:53 +00:00
int aio_read(struct aiocb *);
int aio_write(struct aiocb *);
fix various errors in function signatures/prototypes found by nsz
2011-09-14 01:09:35 +00:00
int aio_error(const struct aiocb *);
implement POSIX asynchronous io some features are not yet supported, and only minimal testing has been performed. should be considered experimental at this point.
2011-09-09 05:07:38 +00:00
ssize_t aio_return(struct aiocb *);
int aio_cancel(int, struct aiocb *);
fix various errors in function signatures/prototypes found by nsz
2011-09-14 01:09:35 +00:00
int aio_suspend(const struct aiocb *const [], int, const struct timespec *);
implement POSIX asynchronous io some features are not yet supported, and only minimal testing has been performed. should be considered experimental at this point.
2011-09-09 05:07:38 +00:00
int aio_fsync(int, struct aiocb *);
use restrict everywhere it's required by c99 and/or posix 2008 to deal with the fact that the public headers may be used with pre-c99 compilers, __restrict is used in place of restrict, and defined appropriately for any supported compiler. we also avoid the form [restrict] since older versions of gcc rejected it due to a bug in the original c99 standard, and instead use the form *restrict.
2012-09-07 02:44:55 +00:00
int lio_listio(int, struct aiocb *__restrict const *__restrict, int, struct sigevent *__restrict);
implement POSIX asynchronous io some features are not yet supported, and only minimal testing has been performed. should be considered experimental at this point.
2011-09-09 05:07:38 +00:00
_GNU_SOURCE is supposed to imply _LARGEFILE64_SOURCE this is ugly and stupid, but now that the *64 symbol names exist, a lot of broken GNU software detects them in configure, then either breaks during build due to missing off64_t definition, or attempts to compile without function declarations/prototypes. "fixing" it here is easier than telling everyone to add yet another feature test macro to their builds.
2012-06-04 12:03:56 +00:00
#if defined(_LARGEFILE64_SOURCE) || defined(_GNU_SOURCE)
add support for ugly *64 functions with _LARGEFILE64_SOURCE musl does not support legacy 32-bit-off_t whatsoever. off_t is always 64 bit, and correct programs that use off_t and the standard functions will just work out of the box. (on glibc, they would require -D_FILE_OFFSET_BITS=64 to work.) however, some programs instead define _LARGEFILE64_SOURCE and use alternate versions of all the standard types and functions with "64" appended to their names. we do not want code to actually get linked against these functions (it's ugly and inconsistent), so macros are used instead of prototypes with weak aliases in the library itself. eventually the weak aliases may be added at the library level for the sake of using code that was originally built against glibc, but the macros will still be the desired solution in the headers.
2012-05-04 04:13:23 +00:00
#define aiocb64 aiocb
#define aio_read64 aio_read
#define aio_write64 aio_write
#define aio_error64 aio_error
#define aio_return64 aio_return
#define aio_cancel64 aio_cancel
#define aio_suspend64 aio_suspend
#define aio_fsync64 aio_fsync
fix typo in aio.h
2012-07-19 04:37:43 +00:00
#define lio_listio64 lio_listio
add support for ugly *64 functions with _LARGEFILE64_SOURCE musl does not support legacy 32-bit-off_t whatsoever. off_t is always 64 bit, and correct programs that use off_t and the standard functions will just work out of the box. (on glibc, they would require -D_FILE_OFFSET_BITS=64 to work.) however, some programs instead define _LARGEFILE64_SOURCE and use alternate versions of all the standard types and functions with "64" appended to their names. we do not want code to actually get linked against these functions (it's ugly and inconsistent), so macros are used instead of prototypes with weak aliases in the library itself. eventually the weak aliases may be added at the library level for the sake of using code that was originally built against glibc, but the macros will still be the desired solution in the headers.
2012-05-04 04:13:23 +00:00
#define off64_t off_t
#endif
implement POSIX asynchronous io some features are not yet supported, and only minimal testing has been performed. should be considered experimental at this point.
2011-09-09 05:07:38 +00:00
#ifdef __cplusplus
}
#endif
#endif