Starpack/XOTcl/Thread exit behavior

[Scott]

I've got a problem where I get different behavior with a starpack vs.
running the same code (& interpreter) unpacked.

My code launches a thread for handling a device. The device is managed
by an XOTcl object, and it registers an XOTcl setExitHandler to save
its state out to a data file on exit.

This code all works fine when I run out of the source tree, but when I
build it into a starpack, it ceases to function correctly. When I exit
from the starpack, the data file is touched but it has no contents.

The problem is kind of funky. I've tried, but so far I've been unable
to reduce it down to a simple test case. I've googled around, but
haven't been able to find anything interesting. Is there any known
differences in behavior between the way a starpack terminates threads
vs the way an interpreter would terminate the thread? Or any known bad
interactions between XOTcl and starpacks and threads?

As I've run into a bit of an impasse, even some debugging suggestions
would useful, Thanks.

Scott

[stephan...@yahoo.fr]

Scott a écrit :

> I've got a problem where I get different behavior with a starpack vs.
> running the same code (& interpreter) unpacked.

> Or any known bad
> interactions between XOTcl and starpacks and threads?
>
> As I've run into a bit of an impasse, even some debugging suggestions
> would useful, Thanks.
>
> Scott

Hi,

All I can do to help you is to encourage you to check that tclkits (the
starpack runners) are thread-safe.
I have tried loading the Thread package in tclkit8.4, 8.5a2 and 8.5a4.
None of them succeed. I guess tclkit is not thread-safe, and if it
would,
wouldn't it include the Thread package ?

Hope it helps
Cheers,

Stéphane

[Scott]

Thanks. I'm using ActiveState's release of Tcl as my runtime, and it
is thread-safe. I can do "package require Thread" successfully, and
the threads launch and work correctly, they just don't shut down right.

I don't believe the interpreter I use to build the starpack (the one
that runs "sdx wrap") is threaded, but I assume that doesn't matter.

[Neil Madden]

One possibility is that it is the metakit database that is used for the
VFS in the starpack that isn't thread-safe. If multiple threads are
accessing files in the VFS concurrently then I guess this could be a
problem. I'm not sure if threaded Tclkits address this already though.
You might want to ask on the starkit mailing list:
http://equi4.com/mailman/listinfo/starkit

-- Neil