Threads on Cygwin
Joshua Gatcomb
were passing on Cygwin. I had submitted a patch some
time ago that never got applied enabling tests for
threads, timer, and extend_13 that never got applied.
I figured there was good reason so I didn't say
anything about the tests failing except an occasional
"that's weird" on #parrot.
So today I decide to look at threads_2.pasm
It says at the bottom that the output could appear in
reversed order and so I am guessing the sleep
statement is to ensure that it comes out in the proper
order.
So - why is the test failing? Because the second
print statement never makes it to the screen.
If I remove the print statement entirely, I see both
things in the reverse expected order.
If I place the sleep statement after the main thread
print then all I get to the screen is the that and not
the print statement from thread 1
It is almost as if by the time the time the second
print happens, the filehandle is already closed
So - since threads aren't officially supposed to be
working on Cygwin - is this something I should care
about or not?
Cheers
Joshua Gatcomb
a.k.a. Limbic~Region
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
Joshua Gatcomb
wrote:
In summary, all code in all threads runs to completion
but whichever thread finishes last can't print to the
screen
$ perl t/harness --gc-debug --running-make-test -b
t/pmc/threads.t
Failed 7/11 tests, 36.36% okay (less 2 skipped
tests: 2 okay, 18.18%)
Failed Test Stat Wstat Total Fail Failed List of
Failed
-------------------------------------------------------------------------------
t/pmc/threads.t 7 1792 11 7 63.64% 2-3 5-9
2 subtests skipped.
Failed 1/1 test scripts, 0.00% okay. 7/11 subtests
failed, 36.36% okay.
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
Leopold Toetsch
> Up until a couple of weeks ago, all the threads tests
> were passing on Cygwin. I had submitted a patch some
> time ago that never got applied enabling tests for
> threads, timer, and extend_13 that never got applied.
Overlooked? Please rediff and resend.
> It says at the bottom that the output could appear in
> reversed order and so I am guessing the sleep
> statement is to ensure that it comes out in the proper
> order.
The "sleep" is of course a hack only and wrong. The real thing todo is
to convert the test result into a regexp that allows both orderings.
leo
Joshua Gatcomb
>> Joshua Gatcomb <limbic_re...@yahoo.com>
wrote:
>> I had submitted a patch some time ago that never
got
>> applied enabling tests for threads, timer, and
>> extend_13.....
> Overlooked? Please rediff and resend.
I will do - likely tomorrow.
> > It says at the bottom that the output could appear
> > in reversed order and so I am guessing the sleep
> > statement is to ensure that it comes out in the
> > proper order.
> The "sleep" is of course a hack only and wrong. The
> real thing todo is to convert the test result into a
> regexp that allows both orderings.
I agree, but that doesn't explain why only 1 of the
two messages is displayed to the screen when the sleep
statement is present. I don't want to brush a bug
under the rug. If one thread finishes before the
other thread gets to a print statement, the print does
not appear on the screen at all.
> leo
Leopold Toetsch
> ... only 1 of the
> two messages is displayed
I've fixed a flaw in the IO flush code. Please try again, thanks.
leo
Leopold Toetsch
> I agree, but that doesn't explain why only 1 of the
> two messages is displayed to the screen when the sleep
> statement is present.
Overlooked that in the first place. So what you get is that the one *or*
the other string is displayed. That's a serious problem, likely related
to the IO subsystem.
So the first question is: which IO system is active on Cygwin: the
windows or the unix variant?
But looking at the source code it seems that the IO system shutdown code
is rather broken: only stdout and stderr streams are flushed but not the
actual PIOs. I'll try to fix that.
> Joshua Gatcomb
leo
Joshua Gatcomb
Still not working, but thanks! The behavior has
changed a bit though.
Here is the behavior prior to the fix - notice the
location of the sleep statement
Case 1:
(as checked out)
$ cat t/pmc/threads_2.pasm <snipped>
set I3, 1
invoke # start the thread
sleep 1
print "main "
print I5
$ ./parrot t/pmc/threads_2.pasm
thread 1
Case 2:
(remove sleep all together)
$ ./parrot t/pmc/threads_2.pasm
main 10
thread 1
Case 3:
$ cat t/pmc/threads_2.pasm <snipped>
invoke # start the thread
print "main "
sleep 1
print I5
$ ./parrot t/pmc/threads_2.pasm
main 10
After the change - case 3 now prints thread 1.
You mentioned in the previous email that you were
interested in knowing if this was Windows IO or the
Cygwin variant. I would love to give you that
information, but color me clueless.
>
> leo
>
Joshua Gatcomb
a.k.a. Limbic~Region
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Leopold Toetsch
> After the change - case 3 now prints thread 1.
Strange.
> You mentioned in the previous email that you were
> interested in knowing if this was Windows IO or the
> Cygwin variant. I would love to give you that
> information, but color me clueless.
S/Cygwin/unix/
Have a look at the defines in include/parrot/io.h. It's not quite
visible which one is active w/o debugger, but you could insert some
print statements in io/io.c:PIO_init_stacks(), where there are explicit
cases for PIO_OS_*.
> Joshua Gatcomb
leo
Joshua Gatcomb
> Joshua Gatcomb <limbic_re...@yahoo.com> wrote:
>
> > After the change - case 3 now prints thread 1.
>
> Strange.
indeed
> > You mentioned in the previous email that you were
> > interested in knowing if this was Windows IO or
> the
> > Cygwin variant. I would love to give you that
> > information, but color me clueless.
>
> S/Cygwin/unix/
>
> Have a look at the defines in include/parrot/io.h.
> It's not quite
> visible which one is active w/o debugger, but you
> could insert some
> print statements in io/io.c:PIO_init_stacks(), where
> there are explicit
> cases for PIO_OS_*.
s/S/s/
PIO_OS_UNIX is the one defined and now parrot squawks
"Polly wanna Unix" everytime I run it ;-)
Now what?
>
> > Joshua Gatcomb
>
> leo
Joshua Gatcomb
a.k.a. Limbic~Region
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
Leopold Toetsch
> PIO_OS_UNIX is the one defined and now parrot squawks
> "Polly wanna Unix" everytime I run it ;-)
> Now what?
Fix the thread related IO bug? Seriously, I don't know yet, if the IO
initialization is done correctly for threads. Currently each thread has
its own IO subsystem, which might be wrong.
It could be that the IO PMCs for standard handles (or for all open
files?) have to be shared between threads.
leo
Leopold Toetsch
[ Cygwin thread tests don't print all ]
Does this patch help? It creates shared IO resources. But its of course
not final: there are no precautions against one thread changing the PIO
of another thread or such, no locks yet, nothing.
leo
--- parrot/src/inter_create.c Fri Oct 1 15:26:26 2004
+++ parrot-leo/src/inter_create.c Sat Oct 2 12:06:10 2004
@@ -31,6 +31,12 @@
#define ATEXIT_DESTROY
/*
+ * experimental: use shared IO resources for threads
+ */
+
+#define PARROT_SHARED_IO 1
+
+/*
=item C<static int is_env_var_set(const char* var)>
@@ -125,7 +131,15 @@
/* PANIC will fail until this is done */
SET_NULL(interpreter->piodata);
+#if PARROT_SHARED_IO
+ if (parent) {
+ interpreter->piodata = parent->piodata;
+ }
+ else
+ PIO_init(interpreter);
+#else
PIO_init(interpreter);
+#endif
if (is_env_var_set("PARROT_GC_DEBUG")) {
#if ! DISABLE_GC_DEBUG
@@ -225,6 +239,9 @@
setup_default_compreg(interpreter);
/* setup stdio PMCs */
+#if PARROT_SHARED_IO
+ if (!parent)
+#endif
PIO_init(interpreter);
/* Done. Return and be done with it */
@@ -330,6 +347,9 @@
*/
/* Now the PIOData gets also cleared */
+#if PARROT_SHARED_IO
+ if (!interpreter->parent_interpreter)
+#endif
PIO_finish(interpreter);
/*
Jens Rieks
> Does this patch help?
No, it makes things worse:
--- without-patch.txt 2004-10-03 14:35:58.824775096 +0200
+++ with-patch.txt 2004-10-03 14:35:37.843964664 +0200
@@ -30,7 +30,12 @@
# expected: '500500
# 500500
# '
-ok 6 - detach
+not ok 6 - detach
+# Failed test (t/pmc/threads.t at line 257)
+# 'thread
+# '
+# doesn't match '/(done\nthread\n)|(thread\ndone\n)/
+# '
not ok 7 - share a PMC
# Failed test (t/pmc/threads.t at line 285)
# got: 'thread
@@ -73,4 +78,4 @@
# '
ok 10 # skip no shared PerlStrings yet
ok 11 # skip no shared PerlStrings yet
-# Looks like you failed 6 tests of 11.
+# Looks like you failed 7 tests of 11.
without-patch.txt:
$ perl -Ilib t/pmc/threads.t
1..11
ok 1 - interp identity
not ok 2 - thread type 1
# Failed test (t/pmc/threads.t at line 61)
# got: 'thread 1
# '
# expected: 'thread 1
# main 10
# '
not ok 3 - thread type 2
# Failed test (t/pmc/threads.t at line 98)
# got: 'ok 1
# ok 2
# hello from 1 thread
# ParrotThread tid 1
# Sub
# '
# expected: 'ok 1
# ok 2
# hello from 1 thread
# ParrotThread tid 1
# Sub
# from 10 interp
# '
ok 4 - thread - kill
not ok 5 - join, get retval
# Failed test (t/pmc/threads.t at line 189)
# got: ''
# expected: '500500
# 500500
# '
not ok 6 - detach
# Failed test (t/pmc/threads.t at line 257)
# 'thread
# '
# doesn't match '/(done\nthread\n)|(thread\ndone\n)/
# '
not ok 7 - share a PMC
# Failed test (t/pmc/threads.t at line 285)
# got: 'thread
# 20
# '
# expected: 'thread
# 20
# done
# 21
# '
not ok 8 - multi-threaded
# Failed test (t/pmc/threads.t at line 320)
# got: '3
# 1
# 2
# 3
# done thread
# '
# expected: '3
# 1
# 2
# 3
# done thread
# done main
# '
not ok 9 - multi-threaded strings via SharedRef
# Failed test (t/pmc/threads.t at line 368)
# got: '3
# ok 1
# ok 2
# ok 3
# done thread
# '
# expected: '3
# ok 1
# ok 2
# ok 3
# done thread
# done main
# '
ok 10 # skip no shared PerlStrings yet
ok 11 # skip no shared PerlStrings yet
# Looks like you failed 7 tests of 11.
without-patch.txt:
$ perl -Ilib t/pmc/threads.t
1..11
ok 1 - interp identity
not ok 2 - thread type 1
# Failed test (t/pmc/threads.t at line 61)
# got: 'thread 1
# '
# expected: 'thread 1
# main 10
# '
not ok 3 - thread type 2
# Failed test (t/pmc/threads.t at line 98)
# got: 'ok 1
# ok 2
# hello from 1 thread
# ParrotThread tid 1
# Sub
# '
# expected: 'ok 1
# ok 2
# hello from 1 thread
# ParrotThread tid 1
# Sub
# from 10 interp
# '
ok 4 - thread - kill
not ok 5 - join, get retval
# Failed test (t/pmc/threads.t at line 189)
# got: ''
# expected: '500500
# 500500
# '
ok 6 - detach
not ok 7 - share a PMC
# Failed test (t/pmc/threads.t at line 285)
# got: 'thread
# 20
# '
# expected: 'thread
# 20
# done
# 21
# '
not ok 8 - multi-threaded
# Failed test (t/pmc/threads.t at line 320)
# got: '3
# 1
# 2
# 3
# done thread
# '
# expected: '3
# 1
# 2
# 3
# done thread
# done main
# '
not ok 9 - multi-threaded strings via SharedRef
# Failed test (t/pmc/threads.t at line 368)
# got: '3
# ok 1
# ok 2
# ok 3
# done thread
# '
# expected: '3
# ok 1
# ok 2
# ok 3
# done thread
# done main
# '
ok 10 # skip no shared PerlStrings yet
ok 11 # skip no shared PerlStrings yet
# Looks like you failed 6 tests of 11.
jens
Joshua Gatcomb
--- Jens Rieks <par...@jensbeimsurfen.de> wrote:
> On Saturday 02 October 2004 12:49, Leopold Toetsch
> wrote:
> > Does this patch help?
> No, it makes things worse:
Actually it doesn't. There is something wrong with
threads_6.pasm as my output for the test doesn't
change with or without the patch and yet one passes
and the other doesn't. Judging from the actual code
it is supposed to print "done" in there somewhere and
it doesn't. Test 6 is one of the few that has a regex
for checking output :
/(done\nthread\n)|(thread\ndone\n)/
So I am rather confused as to why it is passing
without the patch since it only ever prints "thread"
> jens
Joshua Gatcomb
a.k.a. Limbic~Region
__________________________________
Do you Yahoo!?