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 <[email protected]>: > 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: [email protected] > [[email protected]] On Behalf Of Nicolas Cellier > [[email protected]] > 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 <[email protected]>: >> 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
