English (translate):
Adding initialization d.timestamp.finished at the torrent download but is not set seeding. For example when we create a torrent, it is not downloaded.
French:
Ajout de l'initialisation d.timestamp.finished lors que le torrent n'est pas télécharger mais mis en seeding. Par exemple lors que l'on créer un torrent, celui ci n'est pas télécharger.
Added config parameter network.http.ssl_verify_host to support certificates
with a mismatched or empty CN. Default is 2 (verify name match). Use 1 to simply
verify the presence of a name or 0 to allow for missing names.
signal() is known to have portability problems. Some systems such as
old Unix systems and System V employ a behavior in which the signal
disposition is reset to SIG_DFL (default) upon invocation of a signal
handler by the delivery of a signal.
See issue #51 in which Solaris users experience signal-based issues.
Solaris is a system which employs the SIG_DFL reset behavior even in
version 11.1.
See http://docs.oracle.com/cd/E26502_01/html/E29034/signal-3c.html
> If signal() is used, disp is the address of a signal handler, and sig is not SIGILL,
> SIGTRAP, or SIGPWR, the system first sets the signal's disposition to SIG_DFL before
> executing the signal handler.
On Solaris the default signal disposition for SIGUSR1 is to exit the application.
See http://docs.oracle.com/cd/E26502_01/html/E29033/signal.h-3head.html
If I'm correct in assuming this is the problem Solaris users are encountering,
the solution to this (and likely any other portability issues that may arise)
is to use sigaction() which has explicitly defined behavior as per the POSIX standards.
As you can see, it's a pretty drop-in solution. In fact, on some systems such as Linux,
glibc defines signal() as a wrapper around sigaction() to use BSD semantics (i.e. not the
behavior detailed above), which is likely why few others have experienced these problems.
See http://man7.org/linux/man-pages/man2/signal.2.html
rakshasa