[Bug 3841] Crashes when run multithreaded
http://bugzilla.spamassassin.org/show_bug.cgi?id=3841 --- Additional Comments From [EMAIL PROTECTED] 2004-10-21 15:35 --- This should be fixed in trunk now. John, can you test out SVN trunk to see if that solves the problem for you? --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3841] Crashes when run multithreaded
http://bugzilla.spamassassin.org/show_bug.cgi?id=3841 [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|Future |3.1.0 --- Additional Comments From [EMAIL PROTECTED] 2004-10-21 15:35 --- 3.1.0 milestone --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3841] Crashes when run multithreaded
http://bugzilla.spamassassin.org/show_bug.cgi?id=3841
--- Additional Comments From [EMAIL PROTECTED] 2004-10-10 21:07 ---
John,
If you declare 'my %foo' in HTML.pm (line after %tested_colors)
and put '$foo{bar} = rand(1);' in html_text(),
does each thread share the same %foo object?
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
[Bug 3841] Crashes when run multithreaded
http://bugzilla.spamassassin.org/show_bug.cgi?id=3841 --- Additional Comments From [EMAIL PROTECTED] 2004-10-11 08:37 --- Subject: Re: Crashes when run multithreaded daniel, are you working on this? if not, I'll take a look. I am working on this. I have a closure-less version working and am working on an overhauled version for 3.1. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3841] Crashes when run multithreaded
http://bugzilla.spamassassin.org/show_bug.cgi?id=3841 --- Additional Comments From [EMAIL PROTECTED] 2004-10-10 13:30 --- daniel, are you working on this? if not, I'll take a look. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3841] Crashes when run multithreaded
http://bugzilla.spamassassin.org/show_bug.cgi?id=3841
--- Additional Comments From [EMAIL PROTECTED] 2004-09-28 17:57 ---
hmm. actually, both the before and after of that patch are less efficient than
they could be.
- before: is using closures (ie. sub {
$varfromoutsidescope-method($othervars) }), which are explicitly called out as
being slower than simple sub refs
- after: is using eval of a string, and closures, so double-slow
a better solution would be to do the following:
- replace the sub { ... } callbacks with function references of the methods
being called, e.g. start_document = [ \html_start ].
- set a member on the HTML::Parser object to pass out of band any data that
needs to be passed, and then (in the callback) use that to get the
Mail::SpamAssassin::HTML object $self.
so e.g.:
my $hp = HTML::Parser-new(
api_version = 3,
handlers = [
start_document = [ \html_start, self ],
start = [ \html_tag, self,tagname,attr,'+1'],
end_document = [ \html_end, self ],
end = [ \html_tag, self,tagname,attr,'-1'],
text = [ \html_text, self,dtext],
comment = [ \html_comment, self,text],
declaration = [ \html_declaration, self,text],
],
marked_sections = 1);
$hp-{cbobject} = $self;
and change those callback methods to get $self from the first argument passed
into them.
Would that work with ithreads? afaics it should, because they're real
functions defined in the source, not closures.
(PS: A better solution long term would be to use HTML::Parser in its subclassed
form, instead of with these callbacks; that way, $self in the HTML::Parser
callbacks is $self for Mail::SpamAssassin::HTML too ;) one for 3.1.0 maybe.)
(PPS: I guess this means we can't switch to using Singletons for certain objects
for speed, and assuming that there'd only be one Mail::SpamAssassin object per
interpreter, as we were just discussing last night ;)
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
