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
|
This appendix outlines the structure of the program. It serves as a
short reminder for debugging the program.
A running @command{wydawca} process consists of at least four threads.
Each upload is processed by its dedicated thread. Additional threads
can be strarted to perform some specific tasks.
If the operating system permits, each thread is assigned a name.
Apart from the main thread, names of each thread begin with uppercase
letters @sc{WY} plus underscore.
On a GNU/Linux system the name of a thread can be read from
@file{/proc/@var{pid}/task/@var{tid}/comm}, where @var{pid} is the PID
of the @command{wydawca} process and @var{tid} is the thread identifier.
The following table describes each thread:
@table @samp
@item wydawca
The main thread. It starts all other threads and waits for signals.
When it exits, all other threads are terminated as well.
@item WY_listener
The workhorse of the project. Listens on inotify descriptor and TCP
socket for incoming notification events. This thread keeps a table of
uploaded files, which is updated each time an inotify event is
reported. Uploaded files are verified and ordered into triplets. Once
a triplet is completed, a separate @samp{WY_triplet} thread is started
in order to process it.
If an incoming connection appears on upload notification socket
(@pxref{upload notification}), a @samp{WY_tcpmux} thread is started to
handle it.
@item WY_tricleaner
Keeps track of registered triplets and removes expired ones.
@item WY_stat
This thread is responsible for statistic logging and notification.
@item WY_connwatch
This thread is started by if the legacy upload notification is enabled
(@pxref{daemon, listen}). It enforces idle timeout for
all started upload notification threads (@samp{WY_tcpmux} instances).
@item WY_tcpmux
Serves a particular notification upload connection. The number of
threads of this type is limited by the @code{max-connections}
configuration file statement (@pxref{daemon, max-connections}).
@item WY_triplet
Processes a triplet. A separate thread of this type is started by
@samp{WY_listener} for each valid triplet it detects.
@end table
@menu
* Event timestamps in WY_stat::
@end menu
@node Event timestamps in WY_stat
@unnumberedsec Event timestamps in WY_stat
On GNU/Linux systems the events generated by the @samp{WY_stat} thread
may appear to happen one second prior to their scheduled time. This
happens if the software reporting the events uses @code{time}(2)
instead of @code{gettimeofday}(2) for time reporting. The internal
timekeeping mechanism of the linux kernel is designed so that the
number of seconds returned by @code{time} may be one less than the
@code{tv_sec} value after return from @code{gettimeofday}, if the two
functions would be called the same instant@footnote{See
@uref{https://stackoverflow.com/questions/22917318/time-and-gettimeofday-return-different-seconds},
for details}.
The two known cases are the legacy @command{syslogd} used by default
on Slackware systems, and the @command{Sendmail} MTA.
Since the results returned by @code{gettimeofday} are more accurate,
it was decided to leave this feature as it is, instead of installing
workarounds of dubious nature just to satisfy older software.
|
