[dm-devel] device-mapper/dmeventd dmeventd.c
agk at sourceware.org
agk at sourceware.org
Mon Jan 15 19:19:31 UTC 2007
CVSROOT: /cvs/dm
Module name: device-mapper
Changes by: agk at sourceware.org 2007-01-15 19:19:31
Modified files:
dmeventd : dmeventd.c
Log message:
fail registration if timeout thread cannot be started
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/device-mapper/dmeventd/dmeventd.c.diff?cvsroot=dm&r1=1.30&r2=1.31
--- device-mapper/dmeventd/dmeventd.c 2007/01/15 18:58:40 1.30
+++ device-mapper/dmeventd/dmeventd.c 2007/01/15 19:19:31 1.31
@@ -849,6 +849,20 @@
_lock_mutex();
+ /* If creation of timeout thread fails (as it may), we fail
+ here completely. The client is responsible for either
+ retrying later or trying to register without timeout
+ events. However, if timeout thread cannot be started, it
+ usually means we are so starved on resources that we are
+ almost as good as dead already... */
+ if (thread->events & DM_EVENT_TIMEOUT) {
+ ret = -_register_for_timeout(thread);
+ if (ret) {
+ _unlock_mutex();
+ goto out;
+ }
+ }
+
if (!(thread = _lookup_thread_status(message_data))) {
_unlock_mutex();
@@ -874,15 +888,6 @@
_unlock_mutex();
- /* FIXME - If you fail to register for timeout events, you
- still monitor all the other events. Is this the right
- action for newly created devices? Also, you are still
- on the timeout registry, so if a timeout thread is
- successfully started up later, you will start receiving
- DM_EVENT_TIMEOUT events */
- if (thread->events & DM_EVENT_TIMEOUT)
- ret = -_register_for_timeout(thread);
-
out:
/*
* Deallocate thread status after releasing
More information about the dm-devel
mailing list