1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
|
%global _empty_manifest_terminate_build 0
Name: python-libaio
Version: 0.9.1
Release: 1
Summary: Linux AIO API wrapper
License: LGPLv3+
URL: http://github.com/vpelletier/python-libaio
Source0: https://mirrors.aliyun.com/pypi/web/packages/ea/94/4d5466535240f2c8132b1f867bcb62047ecbf31cf2fedeb5592aa9f81969/libaio-0.9.1.tar.gz
BuildArch: noarch
%description
When sending or expecting data, the typical issue a developer faces is knowing
when the operation will complete, so the program can carry on.
- read/write/recv/send: blocks until stuff happened
- same, on a non-blocking file descriptor: errors out instead of blocking,
developper has to implement retry somehow, and may end up wasting CPU time
just resubmitting the same operation over and over.
- select/poll/epoll: kernel tells the program when (re)submitting an operation
should not block (if developer is careful to not have competing IO sources)
AIO is the next level: the application expresses the intention that some IO
operation happens when the file descriptor accepts it *and* provides
corresponding buffer to the kernel.
Compared to select/poll/epoll, this avoids one round-trip to userland when the
operation becomes possible:
- kernel sends notification (ex: fd is readable)
- program initiates actual IO (ex: read from fd)
Instead, kernel only has to notify userland the operation is already completed,
and application may either process received data, or submit more data to send.
%package -n python3-libaio
Summary: Linux AIO API wrapper
Provides: python-libaio
BuildRequires: python3-devel
BuildRequires: python3-setuptools
BuildRequires: python3-pip
%description -n python3-libaio
When sending or expecting data, the typical issue a developer faces is knowing
when the operation will complete, so the program can carry on.
- read/write/recv/send: blocks until stuff happened
- same, on a non-blocking file descriptor: errors out instead of blocking,
developper has to implement retry somehow, and may end up wasting CPU time
just resubmitting the same operation over and over.
- select/poll/epoll: kernel tells the program when (re)submitting an operation
should not block (if developer is careful to not have competing IO sources)
AIO is the next level: the application expresses the intention that some IO
operation happens when the file descriptor accepts it *and* provides
corresponding buffer to the kernel.
Compared to select/poll/epoll, this avoids one round-trip to userland when the
operation becomes possible:
- kernel sends notification (ex: fd is readable)
- program initiates actual IO (ex: read from fd)
Instead, kernel only has to notify userland the operation is already completed,
and application may either process received data, or submit more data to send.
%package help
Summary: Development documents and examples for libaio
Provides: python3-libaio-doc
%description help
When sending or expecting data, the typical issue a developer faces is knowing
when the operation will complete, so the program can carry on.
- read/write/recv/send: blocks until stuff happened
- same, on a non-blocking file descriptor: errors out instead of blocking,
developper has to implement retry somehow, and may end up wasting CPU time
just resubmitting the same operation over and over.
- select/poll/epoll: kernel tells the program when (re)submitting an operation
should not block (if developer is careful to not have competing IO sources)
AIO is the next level: the application expresses the intention that some IO
operation happens when the file descriptor accepts it *and* provides
corresponding buffer to the kernel.
Compared to select/poll/epoll, this avoids one round-trip to userland when the
operation becomes possible:
- kernel sends notification (ex: fd is readable)
- program initiates actual IO (ex: read from fd)
Instead, kernel only has to notify userland the operation is already completed,
and application may either process received data, or submit more data to send.
%prep
%autosetup -n libaio-0.9.1
%build
%py3_build
%install
%py3_install
install -d -m755 %{buildroot}/%{_pkgdocdir}
if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
pushd %{buildroot}
if [ -d usr/lib ]; then
find usr/lib -type f -printf "\"/%h/%f\"\n" >> filelist.lst
fi
if [ -d usr/lib64 ]; then
find usr/lib64 -type f -printf "\"/%h/%f\"\n" >> filelist.lst
fi
if [ -d usr/bin ]; then
find usr/bin -type f -printf "\"/%h/%f\"\n" >> filelist.lst
fi
if [ -d usr/sbin ]; then
find usr/sbin -type f -printf "\"/%h/%f\"\n" >> filelist.lst
fi
touch doclist.lst
if [ -d usr/share/man ]; then
find usr/share/man -type f -printf "\"/%h/%f.gz\"\n" >> doclist.lst
fi
popd
mv %{buildroot}/filelist.lst .
mv %{buildroot}/doclist.lst .
%files -n python3-libaio -f filelist.lst
%dir %{python3_sitelib}/*
%files help -f doclist.lst
%{_docdir}/*
%changelog
* Thu Jun 08 2023 Python_Bot <Python_Bot@openeuler.org> - 0.9.1-1
- Package Spec generated
|
