• Main
• Downloads
• Documentation

Appendix A Architecture of the Wydawca

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:

‘wydawca’

The main thread. It starts all other threads and waits for signals. When it exits, all other threads are terminated as well.

‘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 ‘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.

‘WY_tricleaner’

Keeps track of registered triplets and removes expired ones.

‘WY_stat’

This thread is responsible for statistic logging and notification.

‘WY_connwatch’

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).

‘WY_tcpmux’

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).

‘WY_triplet’

Processes a triplet. A separate thread of this type is started by ‘WY_listener’ for each valid triplet it detects.

Event timestamps in WY_stat

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 instant¹⁰.

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.