New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New thread.t test; reveals Queue bugs on multiprocessor systems #913
Comments
From rkc@sst.ll.mit.edu----------------------------------------------------------------- Beware: I am using a version of 5.00562 that includes Brian Mancuso's Sample output (from Solaris 2.6, dual-processor system, details below):
|
From [Unknown Contact. See original ticket]Update: I just ran the test program many times on a uniprocessor system; the Rob Rob Cunningham wrote:
-- |
From [Unknown Contact. See original ticket]At 02:43 PM 12/3/99 -0500, Rob Cunningham wrote:
I'm not entirely sure that it does. Mainly because of this:
$DataElement's not a lexical, so all the threads are sharing a single Dan ----------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]Dan, It turns out that if you define DataQueue as a "my" variable, a similar % ./thread.t (gdb) core core ================================================ BEGIN { # XXX known trouble with global destruction sub content # create a thread passing args and immedaietly wait for it. # check that lock works ... sub dorecurse $t = new Thread \&dorecurse, map { "ok $_\n" } 6..10; # test that sleep lets other thread run sub islocked : locked { $t = Thread->new(\&islocked, "ok 13\n", "ok 14\n"); { # # First one source and one sink $thr = new Thread \&q_thread; # Now one source and several sinks sub qn_thread{ for ($i=0;$i<$sinks;$i++){ $result = 1; # Verify that we can detach and still finish
|
Migrated from rt.perl.org#1848 (status was 'resolved')
Searchable as RT1848$
The text was updated successfully, but these errors were encountered: