shaba/lvm2
1
0
Fork 0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-22 17:35:59 +03:00
Code Releases Activity

fail registration if timeout thread cannot be started

Browse Source
This commit is contained in:
Alasdair Kergon 2007-01-15 19:19:31 +00:00
parent b2486b3d7d
commit 25f063d8b7
1 changed files with 14 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
daemons/dmeventd/dmeventd.c
View File

@ -849,6 +849,20 @@ static int _register_for_event(struct message_data *message_data)
_lock_mutex(); _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))) { if (!(thread = _lookup_thread_status(message_data))) {
_unlock_mutex(); _unlock_mutex();
@ -874,15 +888,6 @@ static int _register_for_event(struct message_data *message_data)
_unlock_mutex(); _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: out:
/* /*
* Deallocate thread status after releasing * Deallocate thread status after releasing