summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: f95e32a)
raw | patch | inline | side by side (parent: f95e32a)
author | Sebastian Harl <sh@tokkee.org> | |
Fri, 1 Aug 2008 22:50:18 +0000 (00:50 +0200) | ||
committer | Florian Forster <octo@huhu.verplant.org> | |
Mon, 11 Aug 2008 14:54:32 +0000 (16:54 +0200) |
So far, a lock has been placed on @plugins, so that no two threads could
access the list of plugins simultaneously. This could cause problems which in
certain situations could even lead to deadlocks. E.g. when using the perl
plugin in combination with the rrdtool plugin with debugging enabled one would
get hit by the following situation: the perl plugin holds the lock on @plugins
and then dispatches values to the rrdtool plugin from some Perl plugin's read
function. The rrdtool plugin then tries to acquire its cache lock. At the same
time some other plugin dispatches values to the rrdtool plugin as well and
this thread now holds the lock on the rrdtool cache. While holding that lock,
the rrdtool plugin might dispatch a debug logging message and thus calls the
perl plugin's log-callback which tries to get the lock on @plugins thus
causing a deadlock.
This has been resolved by the following two changes:
* Restrict the lock to the list of plugins of one type. This allows to access
e.g. read and log plugins in parallel.
* Unlock the variable before calling the Perl callback function. This
further prevents nested locks.
Signed-off-by: Sebastian Harl <sh@tokkee.org>
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
access the list of plugins simultaneously. This could cause problems which in
certain situations could even lead to deadlocks. E.g. when using the perl
plugin in combination with the rrdtool plugin with debugging enabled one would
get hit by the following situation: the perl plugin holds the lock on @plugins
and then dispatches values to the rrdtool plugin from some Perl plugin's read
function. The rrdtool plugin then tries to acquire its cache lock. At the same
time some other plugin dispatches values to the rrdtool plugin as well and
this thread now holds the lock on the rrdtool cache. While holding that lock,
the rrdtool plugin might dispatch a debug logging message and thus calls the
perl plugin's log-callback which tries to get the lock on @plugins thus
causing a deadlock.
This has been resolved by the following two changes:
* Restrict the lock to the list of plugins of one type. This allows to access
e.g. read and log plugins in parallel.
* Unlock the variable before calling the Perl callback function. This
further prevents nested locks.
Signed-off-by: Sebastian Harl <sh@tokkee.org>
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
bindings/perl/Collectd.pm | patch | blob | history |
index cca349ec7a2c60e9a43dfa4b7030ce2299837d79..afe92b2ccc57b5779f5770601ad4b10b61fe30eb 100644 (file)
sub plugin_call_all {
my $type = shift;
+ my %plugins;
+
our $cb_name = undef;
if (! defined $type) {
return;
}
- lock @plugins;
- foreach my $plugin (keys %{$plugins[$type]}) {
- my $p = $plugins[$type]->{$plugin};
+ {
+ lock %{$plugins[$type]};
+ %plugins = %{$plugins[$type]};
+ }
+
+ foreach my $plugin (keys %plugins) {
+ my $p = $plugins{$plugin};
my $status = 0;
cb_name => $data,
);
- lock @plugins;
+ lock %{$plugins[$type]};
$plugins[$type]->{$name} = \%p;
}
else {
return plugin_unregister_data_set ($name);
}
elsif (defined $plugins[$type]) {
- lock @plugins;
+ lock %{$plugins[$type]};
delete $plugins[$type]->{$name};
}
else {