From 3192923687222271de525c150f0aee579923edcd Mon Sep 17 00:00:00 2001 From: Joachim Nilsson Date: Wed, 4 Feb 2015 20:36:32 +0100 Subject: [PATCH] Add another notice to the API section, again highlighting signalfd caveats! Signed-off-by: Joachim Nilsson --- README.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 24b2b44..30f8f25 100644 --- a/README.md +++ b/README.md @@ -117,10 +117,19 @@ Summary: 3. Enter the event loop with `uev_run()` 4. Leave the event loop with `uev_exit()`, possibly from a callback -**Note:** Make sure to use non-blocking stream I/O! Most hard to find +**Note 1:** Make sure to use non-blocking stream I/O! Most hard to find bugs in event driven applications are due to sockets and files being opened in blocking mode. Be careful out there! +**Note 2:** As mentioned above, a certain amount of care is needed when +dealing with signalfd. This means that if your application, for +instance, uses `system()` you must redesign that to use `fork()`, and +then in the child, unblock all signals blocked by your parent process, +before you run `exec()`. This because Linux does not unblock signals +for your children, and neither does most (all?) C-libraries. An example +of this, from [finit][6], implementing `run()` as a better replacement +to `system()`, which sucks anyawy :) + Example -------