Wydawca |
|
Release Submission Daemon |
Sergey Poznyakoff |
This appendix outlines the structure of the program. It serves as a short reminder for debugging the program.
A running 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 WY plus underscore.
On a GNU/Linux system the name of a thread can be read from
/proc/pid/task/tid/comm, where pid is the PID
of the wydawca
process and tid is the thread identifier.
The following table describes each thread:
The main thread. It starts all other threads and waits for signals. When it exits, all other threads are terminated as well.
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 ‘WY_triplet’ thread is started in order to process it.
If an incoming connection appears on upload notification socket (see upload notification), a ‘WY_tcpmux’ thread is started to handle it.
Keeps track of registered triplets and removes expired ones.
This thread is responsible for statistic logging and notification.
This thread is started by if the legacy upload notification is enabled (see listen). It enforces idle timeout for all started upload notification threads (‘WY_tcpmux’ instances).
Serves a particular notification upload connection. The number of
threads of this type is limited by the max-connections
configuration file statement (see max-connections).
Processes a triplet. A separate thread of this type is started by ‘WY_listener’ for each valid triplet it detects.
On GNU/Linux systems the events generated by the ‘WY_stat’ thread
may appear to happen one second prior to their scheduled time. This
happens if the software reporting the events uses time
(2)
instead of gettimeofday
(2) for time reporting. The internal
timekeeping mechanism of the linux kernel is designed so that the
number of seconds returned by time
may be one less than the
tv_sec
value after return from gettimeofday
, if the two
functions would be called the same instant10.
The two known cases are the legacy syslogd
used by default
on Slackware systems, and the Sendmail
MTA.
Since the results returned by 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.
See https://stackoverflow.com/questions/22917318/time-and-gettimeofday-return-different-seconds, for details
This document was generated on January 6, 2021 using makeinfo.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.