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
|
.\" Copyright (C) 2006, 2010 Michael Kerrisk <mtk.manpages@gmail.com>
.\" Copyright (C) 2009 Petr Baudis <pasky@suse.cz>
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.TH sigevent 7 2022-10-30 "Linux man-pages 6.03"
.SH NAME
sigevent \- structure for notification from asynchronous routines
.SH SYNOPSIS
.nf
#include <signal.h>
.PP
union sigval { /* Data passed with notification */
int sival_int; /* Integer value */
void *sival_ptr; /* Pointer value */
};
.PP
struct sigevent {
int sigev_notify; /* Notification method */
int sigev_signo; /* Notification signal */
union sigval sigev_value;
/* Data passed with notification */
void (*sigev_notify_function)(union sigval);
/* Function used for thread
notification (SIGEV_THREAD) */
void *sigev_notify_attributes;
/* Attributes for notification thread
(SIGEV_THREAD) */
pid_t sigev_notify_thread_id;
/* ID of thread to signal
(SIGEV_THREAD_ID); Linux-specific */
};
.fi
.SH DESCRIPTION
The
.I sigevent
structure is used by various APIs
to describe the way a process is to be notified about an event
(e.g., completion of an asynchronous request, expiration of a timer,
or the arrival of a message).
.PP
The definition shown in the SYNOPSIS is approximate:
some of the fields in the
.I sigevent
structure may be defined as part of a union.
Programs should employ only those fields relevant
to the value specified in
.IR sigev_notify .
.PP
The
.I sigev_notify
field specifies how notification is to be performed.
This field can have one of the following values:
.TP
.B SIGEV_NONE
A "null" notification: don't do anything when the event occurs.
.TP
.B SIGEV_SIGNAL
Notify the process by sending the signal specified in
.IR sigev_signo .
.IP
If the signal is caught with a signal handler that was registered using the
.BR sigaction (2)
.B SA_SIGINFO
flag, then the following fields are set in the
.I siginfo_t
structure that is passed as the second argument of the handler:
.RS
.TP 10
.I si_code
This field is set to a value that depends on the API
delivering the notification.
.TP
.I si_signo
This field is set to the signal number (i.e., the same value as in
.IR sigev_signo ).
.TP
.I si_value
This field is set to the value specified in
.IR sigev_value .
.RE
.IP
Depending on the API, other fields may also be set in the
.I siginfo_t
structure.
.IP
The same information is also available if the signal is accepted using
.BR sigwaitinfo (2).
.TP
.B SIGEV_THREAD
Notify the process by invoking
.I sigev_notify_function
"as if" it were the start function of a new thread.
(Among the implementation possibilities here are that
each timer notification could result in the creation of a new thread,
or that a single thread is created to receive all notifications.)
The function is invoked with
.I sigev_value
as its sole argument.
If
.I sigev_notify_attributes
is not NULL, it should point to a
.I pthread_attr_t
structure that defines attributes for the new thread (see
.BR pthread_attr_init (3)).
.TP
.BR SIGEV_THREAD_ID " (Linux-specific)"
.\" | SIGEV_SIGNAL vs not?
Currently used only by POSIX timers; see
.BR timer_create (2).
.SH SEE ALSO
.BR timer_create (2),
.BR aio_fsync (3),
.BR aio_read (3),
.BR aio_write (3),
.BR getaddrinfo_a (3),
.BR lio_listio (3),
.BR mq_notify (3),
.BR aio (7),
.BR pthreads (7)
|
