Re: IPC::IDT Argumenmt isn't numeric in subtraction (at LDT.pm line 1131)

Hi Jochen,

Thanks for the speedy reply and apologies to the list for
the blank mails (I blame IE (my fault for using it though I
guess)).

--- Jochen Stenzel wrote: 
> > This code is called from an Event 0.81 io watcher, and
> > $socket is $event->w->fd.
> 
> Well, this *should* work, but honestly spoken I never
> tried it this way.
> I usually make the IPC::LDT object *with* the socket and
> pass it as an
> argument to the callback, avoiding to construct (and
> destroy) an
> IPC::LDT object with every callback invokation.

Fine as long as you don't want to send messages via a
socket created after registration of the watcher (unless
you create a registry of sockets, which seems pretty nasty
to me).

Part of my code uses preopened sockets and part does not,
so I converted the part that did to use the method you
described...

> Here's a simplified example:
> 
> - snip --
...
> - snip --
> 

... and this solved the problem. The send_socket coupled
with the receive_socket used by the code was used by
several different event callback functions to send messages
(nasty, perhaps), but as I understand it the nature of the
event handler is that everything runs in a single thread,
and therefore that there will be only one attempt to write
to the socket at any one time. Does anyone know if the
event handler really fork()s?

> > Argument "^E^D^B" isn't numeric in subtraction (-) at
> > <perlpath>/lib/site_perl/5.6.0/IPC/LDT.pm line 1131.
> 
> Hm. Is it possible to send me code to reproduce this
> behaviour? I wonder
> where this string comes from ...

It's entirely reproducable with my code, but I can't
release that I'm afraid. I might try to trim it down to
isolate the problem and post an example, but now it works I
might not get around to it ;-).

The message being sent was generated by the line:

  my %msg = ( what=>"SCAN_BAY" );

Out of interest, later errors caused by subsequent calls to
the message handling callback produced different strings in
the error message, some of which I recognised as data from
my message hash.
I also observed that the message handler received a large
number of calls once $ldt->receive had failed, suggesting
that we'd lost the message header and were being sent the
rest of the data. Presumably $ldt->receive eats the header
in order to check for validity...

Anyway, thanks again for the help.

Alex Farrell.


____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie