Re: [Perlunit-devel] Suggestions for a PerlUnit conundrum?

[Matthias F. <mf...@hi...>]

Whoa... so many issues from the past, all hitting at once.  Reminds me of
a James Hogan story I read once.  Anyway.

Named pipes have all the same problems as message queues, unfortunately.
All three of the main IPC tools -- those two and shared memory -- use OS
constructs that don't go away on their own.  I chose message queues
because it's best at handling discrete, sequential messages, which is what
I needed.

I handled the problem in the script that runs the test by having it check
first for existing message queues that may have been left behind by
unfinished runs in the past and giving the user a chance to delete them.
It's not perfect, and more to the point it's not (and cannot be) part of
the test framework.

So I'm not sure what to with this.  Do you think it's worth considering as
part of the framework, with a big fat warning or two in the POD?

Matthias

On Thu, 20 Jun 2002, Adam Spiers wrote:

> Matthias Ferber (mf...@hi...) wrote:
> > I've written a TestDecorator for PerlUnit that runs the tests in a suite
> > in parallel -- a very useful feature when testing the results of a series
> > of web queries, since they're time consuming.  (I did this a while ago in
> > JUnit, but it was rather easier there thanks to threading.) 
> > 
> > The problem I've hit has to do with the interprocess communication.  I
> > used the Perl built-in interface to SysV message queues -- msgsnd, msgrcv,
> > etc., or rather the SysV::* wrapper classes -- to let the parallel test
> > results be combined into one result set.  The problem is that the message
> > queue or queues created will never get cleaned up if the test is cancelled
> > by the user or crashes; they'll just clutter up the OS.  And trying to
> > trap signals to clean up the mess on exit is, by all accounts, impossible
> > to do reliably and safely. 
> > 
> > Any suggestions from PerlUnitLand?  I'd welcome either practical solutions
> > to this problem, or even suggestions for another approach entirely.  My
> > ulterior motive is that I think this decorator is useful enough to be made
> > public, possibly even bundled with PerlUnit, but I don't want to do that
> > unless it's more robust than this. 
> 
> This sounds like very interesting work which it would be great to
> integrate into the main tree.  Unfortunately my knowledge of IPC is
> very limited so I'm afraid I can't really be of much help.  I don't
> suppose named pipes could be of any use?
> 
> 
> -------------------------------------------------------
>                    Bringing you mounds of caffeinated joy
>                    >>>     http://thinkgeek.com/sf    <<<
> 
> _______________________________________________
> Perlunit-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perlunit-devel
>