xevion/v2.xevion.dev
1
0
Fork 0
mirror of https://github.com/Xevion/v2.xevion.dev.git synced 2025-12-09 12:09:15 -06:00
Code Issues Packages Projects Releases Wiki Activity

Fix line-break in post tags in Race Conditions post

Browse Source
This commit is contained in:
Xevion
2023-09-19 12:01:52 -05:00
parent 6daabbb50f
commit 3147f8083f
2 changed files with 8 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
_posts/2023-07-26-race-conditions-in-signal-handlers.md
View File

@@ -1,10 +1,9 @@
---
layout: default
title: Race Conditions in Signal Handlers
date: 2023-07-26 16:08:12 -0500
tags: tar signals interrupt handler process unix race-condition
_preview_description: Signals offer a unique, low-level way of communicating with processes. But under certain
circumstances, they can kill processes, even when they should work.
title: Race Conditions in Signal Handlers
date: 2023-07-26 16:08:12 -0500
tags: tar signals interrupt handler process unix race-condition
_preview_description: Signals offer a unique, low-level way of communicating with processes. But under certain circumstances, they can kill processes, even when they should work.
---
Signals offer a unique, low-level way of communicating with processes. But under certain circumstances, they can kill
@@ -104,7 +103,7 @@ I am still not sure as to how signal handlers are implemented - I would've assum
registered at program start, but that doesn't seem to be the case - or at least, Python can beat them to the punch.
Whatever the case, the issue with my implementation is that the signal is sent before the handler is registered, and
the default behavior of the signal takes over. For many signals (including the one[s] I was using), this is to terminate
the default behavior of the signal takes over. For many signals (including the one\[s] I was using), this is to **terminate**
the process.
## How to wait for Signal Handlers