From: dave.joubert on
On Nov 29, 10:08 pm, "dave.joub...(a)googlemail.com"
<dave.joub...(a)googlemail.com> wrote:
> On Nov 29, 9:33 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
> wrote:
<snip>
> > Instead, this message means that there is no longer any event source.
<snip>
> > -Alex
>
> OK, thanks. I will trace through the code. At the moment, the remote
> app goes down at the same time (according to human perception) but you
> are more that likely right, and the order of events are reversed.
>
<snip>
> Dave

Yes, valgrind shows that the remote binary is crashing with a memory
error, and bringing my app down.

Dave
From: Alexandre Ferrieux on
On Nov 29, 11:28 pm, "dave.joub...(a)googlemail.com"
<dave.joub...(a)googlemail.com> wrote:
>
> Yes, valgrind shows that the remote binary is crashing with a memory
> error, and bringing my app down.

Friendly advice: when the architecture allows it, use the separation
of processes as the first line of investigation. Wireshark and strace
will save you and (everybody else) many hours barking up the wrong
tree.

-Alex

From: dave.joubert on
On Nov 29, 11:45 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
wrote:
<snip>
> will save you and (everybody else) many hours barking up the wrong
> tree.
>
> -Alex

Hmmm... Yes. But the original query was caused by the difference
between my expectation and reality.

My expectation: The other app would crash, and my app would just sit
there doing nothing. The crash on the other app is blinding obvious,
since it is instance of the FreeWRL VRML/X3D browser.

Reality: Tcl knows that the var will not change, and terminates. I
certainly did not expect that.

I probably spend too much time thinking with a server mindset; I
expect my code to keep on running even as the rest of the world falls
to bits.

So, I apologise for not thinking out of the box....

Dave