unix: don't abort loop initalization #1522
Conversation
|
Can you make a separate commit/pull request for the unix/thread.c changes? |
There are several conditions which could cause uv_loop_init() (and by extension uv_loop_new()) to trigger an SIGABRT. This includes mutex initialization failure or running out of FDs. This patch removes the abort()s and returns error codes instead. Cleaning up prior initialization if something has actually failed.
LinuxJedi
force-pushed
the
graceful_loop_init
branch
from
0b2b66e to
2762f73
Compare
|
Changed this pull request to just the loop.c file. Will submit the other shortly |
|
There is also a signal watcher which is started for monitoring child processes which we should also check for failure. |
|
almost makes you wish C had exceptions :) I'll take a look ASAP. |
|
Also, despite many hating goto, it would help here: do all cleanup at the end of the function, using different labels. |
|
well, I was thinking initially of calling uv__loop_close() for cleanup, but that function assumes that init was good, Maybe a cleanup function instead of goto? |
|
There is not much to cleanup, the key thing is what needs to be cleaned up, depending on where the failure occurs. |
|
Ping? |
|
Sorry! Between conference talks and project deadlines I haven't had a lot of time to revisit this. I'll aim to take another look in the next week. |
There are several conditions which could cause uv_loop_init() (and by
extension uv_loop_new()) to trigger an SIGABRT. This includes mutex
initialization failure or running out of FDs.
This patch removes the abort()s and returns error codes instead.
Cleaning up prior initialization if something has actually failed.
Fixes #1519