Odd scalar behaviour

SimonPratt has asked for the wisdom of the Perl Monks concerning the following question:

Hi, Monks

Not really sure where to start with this issue, so I'll try and describe it as best I can and see whether anyone has heard of anything like this before. Please bear with me and let me know if I can provide any further details.

I'm building an OO based communication system utilising Microsoft MSMQ and multithreaded Perl v 5.16.2

The design uses one thread to receive message alerts from MSMQ and queue the message ID numbers for multiple separate worker threads to work on. I'm using threads to create the threads and Thread::Queue to control the queues internal to Perl. The worker thread creates an object representing the open MSMQ queue, then listens to the Thread::Queue for message ID numbers. When an ID comes in, it assigns the ID to the MSMQ object and requests the MSMQ message to be returned.

The problem occurs when I retrieve the message ID from the Thread::Queue, pass it directly to the MSMQ object and ask for the message - Nothing comes back. If I add a print statement to print out the message ID before requesting the message from the MSMQ object, everything works perfectly.

Works:

while($$queueObject{msmqLookupId} = $$self->{queue}->dequeue())
{
  print "$$queueObject{msmqLookupId}\n";
  &{$$self->{handler}}($queueObject->peekMessage());
}
[download]

Doesn't work:

while($$queueObject{msmqLookupId} = $$self->{queue}->dequeue())
{
  &{$$self->{handler}}($queueObject->peekMessage());
}
[download]

Also doesn't work (though the print statement does print the correct value):

while($$queueObject{msmqLookupId} = $$self->{queue}->dequeue())
{
  &{$$self->{handler}}($queueObject->peekMessage());
  print "$$queueObject{msmqLookupId}\n";
}
[download]

Does anyone have any idea what might be occurring here? The only thing I can think of is that Perl is doing something odd with the assignment of the scalar (such as assuming it isn't required and so not assigning it).

Comment on Odd scalar behaviour Select or Download Code

Replies are listed 'Best First'.
Re: Odd scalar behaviour (Odd programmer behaviour) by BrowserUk (Patriarch) on Mar 19, 2014 at 18:34 UTC
My suspicion is that you are attempting to share object handles between threads and they are losing the blessings. But if that is the case; you ought to be receiving some nice informative messages telling you almost exactly that. (You wouldn't be (...) trying to program code this complex without strict and warnings would you?) I also strongly suspect that this is more Odd Programmer Behaviour than your title. If you want help, post testable code; not three repetitions of a single, obfuscated snippet that whilst it might be the site of the symptoms, almost certainly isn't the site of either the cause or the fix. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re: Odd scalar behaviour by choroba (Cardinal) on Mar 19, 2014 at 17:25 UTC
I find it quite uneasy to translate this to the Perl dialect I know. Instead of `$$queue{id}`, I would write `$queue->{id}`. Do I understand it correctly, that `$self` is not an object, but a reference to an object, which itself is a blessed hash reference? What does `peekMessage` do? It seems to depend on the fact whether stringification happened on `$queueObject->{msmqLookupId}`. لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ	[reply] [d/l] [select]
Re^2: Odd scalar behaviour by SimonPratt (Friar) on Mar 20, 2014 at 08:39 UTC
Yes, you understand it correctly. I just wasn't sure how else to get the thread to access the parent object without passing in a reference to the object. (I'm all ears if someone could explain how I could do this in a better way?) I've just gone with that style, as it is a style that everyone in the office here will understand. `peekMessage` is a wrapper around the OLE `PeekByLookupId`, intended to do a little bit of verification before attempting to access the OLE interface to MSMQ. You appear to be quite right in that it depends on stringification of the ID. I've added an sprintf to `peekMessage` and it now works perfectly without attempting a print	[reply] [d/l] [select]
Re: Odd scalar behaviour by kennethk (Abbot) on Mar 19, 2014 at 18:12 UTC
Which OO framework are you using? Can you show us the object declarations? My best guess is that someone overloaded stringification of the object in question (whatever is getting returned from `$$self->{queue}->dequeue()`) and some predicate in `peekMessage` is dodging an uninitialized value. #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.	[reply] [d/l] [select]
Re^2: Odd scalar behaviour by SimonPratt (Friar) on Mar 20, 2014 at 08:48 UTC
I'm not using a framework (probably my first mistake :-)) Sure: `sub new { my $class = shift; my $self = fields::new($class); my %params = @_; die "ID not defined\n" unless $params{ID}; $$self{id} = $params{ID}; $$self{queue} = Thread::Queue->new(); $$self{handler} = $handler_map{$params{HANDLER}}; $$self{processThread} = threads->new(\&worker, \$self, %params); # Note: No need to explicitly bless the object, as it is already ble +ssed. return $self; }` [download] The `$$self{processThread} = threads->new(\&worker, \$self, %params);` line I am really not sure about. I need the worker thread to know which object it is part of (so it knows which Thread::Queue to watch), but it seems a bit clunky to me to effectively be passing in a reference to itself	[reply] [d/l] [select]