Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[sanity] qb_log_fini should assuredly (by the means of a guard) only be called from whatever thread but the logging worker #290

Open
jnpkrn opened this issue Jan 19, 2018 · 0 comments
Labels

Comments

@jnpkrn
Copy link
Contributor

jnpkrn commented Jan 19, 2018

...which could possibly lead to deadlock or other funny moments.

This is to prevent situation like SIGSEGV handler, deliberately and
acceptably calling qb_log_fini (like corosync does) being unknowingly
arranged also for the logging worker should the SIGSEGV be raised
in its context:

"A signal may be generated (and thus pending) for a process as
a whole (e.g., when sent using kill(2)) or for a specific thread
(e.g., certain signals, such as SIGSEGV and SIGFPE, generated as
a consequence of executing a specific machine-language instruction
are thread directed, as are signals targeted at a specific thread
using pthread_kill(3)).  A process-directed signal may be delivered
to any one of the threads that does not currently have the signal
blocked.  If more than one of the threads has the signal unblocked,
then the kernel chooses an arbitrary thread to which to deliver the
signal." [signal(7)]

Consider, for example, that the main thread performs, sequentially,
logging to blackbox, which could possibly result in another nasty race.

@jnpkrn jnpkrn added the design label Jan 19, 2018
@jnpkrn jnpkrn changed the title {sanity] qb_log_fini should assuredly only be called from whatever thread but the logging worker [sanity] qb_log_fini should assuredly (by the means of a guard) only be called from whatever thread but the logging worker Jan 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant