Thomas Karcher wrote:
Hi Dean,
If someone from the ithreads development team is listening: I guess this
is an issue worth considering to have a solution for ... e. g. a
thread-safe array (similar to Thread::Queue) or a more fine-granular
locking mechanism for shared arrays ... not that I
Jerry D. Hedden wrote:
perhaps we could just provide a function:
$y = shared_clone($x);
What name should this function have?
shared_clone()
clone()
shared_copy()
copy()
make_shared()
Or something else?
I'd vote against clone() or copy(), as they're too
general.
Dean Arnold wrote:
Jerry D. Hedden wrote:
Conceptually, I think it would require keeping a weak
reference of each private SV associated with a shared SV.
This would need to be done on a per-thread basis. Then when
a thread tries to reference a shared SV, a lookup would be
made to see
Jerry D. Hedden wrote:
What are your thoughts regarding structures that mix shared
and non-shared elements? Should a whole separate clone be
made, or should that shared portions (i.e., refs) be used in
the copy? (I'm thinking the latter, while messier, makes
more sense.)
I agree. That most
Jerry D. Hedden wrote:
I've attached my reworked version of T::Q that I think takes
care of circular references. Would you mind giving it a
going over? (It passes all the currents tests in its test
suite, so I know I didn't break anything.) Thanks.
My sample worked OK *after* I removed the
Jerry D. Hedden wrote:
erry D. Hedden wrote:
Look at $x:
REF(0x144f8f0)
REF(0x144f8f0)
REF(0x144f8f0)
REF(0x144f8f0)
REF(0x144f8f0)
REF(0x144f8f0)
First look at $y:
SCALAR(0x1423c70)
SCALAR(0x1423ad8)
SCALAR(0x14bd968)
SCALAR(0x14bd980)
Jerry D. Hedden wrote:
Is this a logical approach? If so, is it doable?
If circular references can't be fully supported in
threads::shared, then I need to document this in its POD and
in Thread::Queue's POD, too. Do you agree?
I don't know that they can't be supported; but they do
need
Dean Arnold wrote:
Jerry D. Hedden wrote:
Dean Arnold wrote:
I've been pouring over the p5p archives trying to find
what the subject p5p summary item is about, but wo/ any luck.
Can someone point out the relevent thread title, or maybe
summarize what threads::shared could share aggregates
,
Dean Arnold
, and probably most other
GUI libs, due to the event control loop).
Good luck,
Dean Arnold
Octavian Rasnita wrote:
Passing messages to a window might not seem very complicated, but if
there are more windows, and many rules based on admin's preferences, on
user's schedule, or by user's request, might make the program a
spaghetti application. I think what I want to do should be a
Dave Mitchell wrote:
On Wed, Feb 27, 2008 at 08:15:36AM -0800, Dean Arnold wrote:
As to shared object destruction:
pre-5.10.0: once per thread, requires some extra bookkeeping to make sure
it does the right thing
5.10.0: once in the last referencing thread (fixed in CORE)
Huh?
use
rarely, so it is (and hopefully someday, will be) much
faster.
But the overhead issues still apply.
Every inter-thread operation is expensive.
Thanks,
Shmuel.
HTH,
Dean Arnold
Presicient Corp.
assuming thread A is running an instance of class XYZ with
method callme(), and thread B is running an instance of class DEF that
holds a proxy object $threadA to thread A's apartment, then thread B can call
$threadA-callme() directly, ie, no closures needed.
But the overhead issues still apply.
Dean
stdin_to_client() gets its exit.
Dean Arnold
Presicient Corp.
Jerry D. Hedden wrote:
The attached patches fix this bug. Thank to Dean Arnold for the
suggestion to use a PL_ function pointer.
Just to double check: does this permit *any*
blessed, tied SV to make use of this feature
(assuming it's tie module chains the PL_destroyhook) ?
Or only threads
in the context
of the thread which is about to cause refcount to drop to zero.
OTOH, I suppose thats a lot of work to avoid a simple
if (refcnt() == 1) {} in the DESTROY code. But it does
feel a bit more natural.
Dean Arnold
...but that could
require mutexes if multiple threads are concurrently
destroying)
Alternately, you might try using a threads::shared version
of the object, tho that will complicate your constructor.
You may eventually need to do a deeper debug of your segfault
to get exact lines where the fault occurs.
Dean
Brian Foddy wrote:
Using Solaris 2.8 and Perl v5.8.7 built for sun4-solaris-thread-multi
What version of threads and threads::shared are you using ?
Those modules have been dual-lifed for awhile now, and the
recent CPAN versions tend to behave better than older CORE
versions.
Dean Arnold
there's
an equivalent in *nix using /dev/tty or somesuch, but my
POSIX system programmer skills are a bit rusty.
Dean Arnold
Presicient Corp.
-thread stack size. See
http://search.cpan.org/~jdhedden/threads-1.53/threads.pm#THREAD_STACK_SIZE
and
http://www.perlmonks.com/?node_id=533058
for details.
HTH,
Dean Arnold
Presicient Corp.
Christopher Fowler wrote:
I think I'm understanding things correctly. I've started on my second
exercise and have working code. Here is the basics of the program
1. It does a ping heartbeat on various hosts
2. A piece of data is shared among threads.
3. There is a thread for each target.
simplified it
4) I've replaced your @obj ad-hoc queue with Thread::Queue, which handles
the needed locking (which it appears you weren't applying)
Code below. NOTE: I've not run it, it likely has some syntax errors.
HTH,
Dean Arnold
Presicient Corp.
package Packet;
use threads;
use threads
Dean Arnold wrote:
Christopher Fowler wrote:
On Tue, 2006-10-10 at 09:23 -0500, Michael J. Pomraning wrote:
I've done a quick rewrite of your example (note I have no idea what
the function of your script is, but the Packet class is a pretty simple
container
class, so hopefully this captures
24 matches
Mail list logo
