Re: [Pharo-project] Help request on Xtreams tests with forked process [ was Xtreams : first embryonary port on Squeak ]
Hi Bill, I see, you're helping me to help myself :) What I was looking at was more like a free lunch ;) Nicolas 2010/10/10 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Nicolas,
#fork in a test? Â Do you mean like the code below? Â The thread running the test waits on something signaled toward the end of the forked thread.
If you want a watchdog timer, you could fork another thread that waits on a delay, sets an error flag (best to use a shared queue or a mutex to avoid weirdness) and then signals the test semaphore. Â You might also want to use #ifCurtailed: to set an error flag and wrap that with #ensure: to signal the semaphore. Â You don't necessarily need to be perfect about signaling the semaphore because failure to do so is not much different from your test going into an infinite loop (actually more benign because the stack isn't growing); you'll realize it, break, and figure out what didn't happen or at least "that it didn't" and try again forewarned.
Does that help?
Bill
testLocalServerAndClient     "11-09 - try a server and a client in the same image."
        | server port client serverSocket serverSocketStream text thread done read |
    port := 4900.     done := Semaphore new.
    "11-09 - gag the prompter below"     serverSocket := nil.
    server := ConnectionQueue portNumber:port queueLength:5.     [         client := SocketStream openConnectionToHostNamed:'localhost' port:port.         [ serverSocket isNil ] whileTrue:[             serverSocket := server getConnectionOrNil.         ].
        serverSocketStream := SocketStream on:serverSocket.         text := 'Long live Tux!'.         serverSocketStream nextPutAll:text; flush.
        "11-09 - this hung up w/o the thread.         11-09 - as you were; the problem was a lack of #flush on the send side, so there was         nothing for the client side to read."         thread := [             read := client nextMany:text size.             done signal.         ] forkAt:Processor userBackgroundPriority.         thread name:'READ'.
        done wait.         self should:[ read = text ].         Transcript nextPutAll:'Just to make the point, we read: '; nextPutAll:read; cr; flush.
    ] ensure:[         server destroy.         serverSocketStream close.         client close.     ].
    "11-09 - no prompts"     serverSocket := serverSocket.     client := client.     serverSocketStream := serverSocketStream.     thread := thread.
    "         NetworkSmokeTestCase prod:#testLocalServerAndClient.     "
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] Sent: Sunday, October 10, 2010 7:05 AM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on   Squeak
2010/10/10 Levente Uzonyi <leves@elte.hu>:
On Sun, 10 Oct 2010, Nicolas Cellier wrote:
THE STATUS OF TESTS:
Tests do not all pass. There seems to be a bug in Squeak #replace:from:to:with: when the replacement is the collection itself, moved to the right (this is with a COG VM).
#replace:from:to:with: is not supposed to work for moves. IIRC the primitive version uses memcpy (or strncpy), so moving to the left works just because the undelying C function supports it. I used to (ab)use this feature though.
Levente
OK, since we use memcpy rather than memmove in Squeak VM, I implemented the trivial work around - move through a motionBuffer temporary copy.
I now have a single test failing, XTCollectionWriteStream>>#testReadWriteLargeAmount and this must be due to my #after:do: simplistic implementation. Messing with #fork in SUnit TestCase is tricky, and I need help on this point.
Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Nicolas, I'm told there is no such thing as a free lunch<g>, but if you tell me what you want the menu to look like, I might have something that would be useful. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] Sent: Sunday, October 10, 2010 2:45 PM To: Pharo-project@lists.gforge.inria.fr; The general-purpose Squeak developers list Subject: Re: [Pharo-project] Help request on Xtreams tests with forked process [ was Xtreams : first embryonary port on Squeak ] Hi Bill, I see, you're helping me to help myself :) What I was looking at was more like a free lunch ;) Nicolas 2010/10/10 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Nicolas,
#fork in a test? Do you mean like the code below? The thread running the test waits on something signaled toward the end of the forked thread.
If you want a watchdog timer, you could fork another thread that waits on a delay, sets an error flag (best to use a shared queue or a mutex to avoid weirdness) and then signals the test semaphore. You might also want to use #ifCurtailed: to set an error flag and wrap that with #ensure: to signal the semaphore. You don't necessarily need to be perfect about signaling the semaphore because failure to do so is not much different from your test going into an infinite loop (actually more benign because the stack isn't growing); you'll realize it, break, and figure out what didn't happen or at least "that it didn't" and try again forewarned.
Does that help?
Bill
testLocalServerAndClient "11-09 - try a server and a client in the same image."
| server port client serverSocket serverSocketStream text thread done read |
port := 4900. done := Semaphore new.
"11-09 - gag the prompter below" serverSocket := nil.
server := ConnectionQueue portNumber:port queueLength:5. [ client := SocketStream openConnectionToHostNamed:'localhost' port:port. [ serverSocket isNil ] whileTrue:[ serverSocket := server getConnectionOrNil. ].
serverSocketStream := SocketStream on:serverSocket. text := 'Long live Tux!'. serverSocketStream nextPutAll:text; flush.
"11-09 - this hung up w/o the thread. 11-09 - as you were; the problem was a lack of #flush on the send side, so there was nothing for the client side to read." thread := [ read := client nextMany:text size. done signal. ] forkAt:Processor userBackgroundPriority. thread name:'READ'.
done wait. self should:[ read = text ]. Transcript nextPutAll:'Just to make the point, we read: '; nextPutAll:read; cr; flush.
] ensure:[ server destroy. serverSocketStream close. client close. ].
"11-09 - no prompts" serverSocket := serverSocket. client := client. serverSocketStream := serverSocketStream. thread := thread.
" NetworkSmokeTestCase prod:#testLocalServerAndClient. "
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] Sent: Sunday, October 10, 2010 7:05 AM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on Squeak
2010/10/10 Levente Uzonyi <leves@elte.hu>:
On Sun, 10 Oct 2010, Nicolas Cellier wrote:
THE STATUS OF TESTS:
Tests do not all pass. There seems to be a bug in Squeak #replace:from:to:with: when the replacement is the collection itself, moved to the right (this is with a COG VM).
#replace:from:to:with: is not supposed to work for moves. IIRC the primitive version uses memcpy (or strncpy), so moving to the left works just because the undelying C function supports it. I used to (ab)use this feature though.
Levente
OK, since we use memcpy rather than memmove in Squeak VM, I implemented the trivial work around - move through a motionBuffer temporary copy.
I now have a single test failing, XTCollectionWriteStream>>#testReadWriteLargeAmount and this must be due to my #after:do: simplistic implementation. Messing with #fork in SUnit TestCase is tricky, and I need help on this point.
Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Nicolas Cellier -
Schwab,Wilhelm K