Re: Concurrency testing

On Wed, Oct 7, 2009 at 5:33 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Oct 7, 2009, at 5:18 PM, Jeff Janes wrote:
>
>> I'd much rather live without Test::More and use DBD::Pg, then have
>> Test::More but need to open pipes to psql to talk to the database,
>> rather than using DBI to do it.  But I guess we would need to worry
>> about whether we can make DBD::Pg work with the installation being
>> tested, rather than finding some other install.
>
> The test architecture depends on Perl, but not on the DBI. I don't think
> that Andrew wants to add any dependencies. Therefore we'd need to use file
> handles.

If we are going to talk to multiple psql pipes at the same time, and
not self-deadlock in the process, we would probably need to use some
form of non-blocking IO. Unfortunately, I've often found it isn't as
easy as one might hope to do that in a completely portable way. Maybe
IPC::Run, but I think that that is non-core also.

Are we interested only in simple deterministic concurrency testing: T1
does A, T2 does B, T1 does C and must block until T2 does D, at which
point (and not before) T1 must respond with E. (Of course from some
recent testing I've done, we would also want "T1 does C and must block
either until T2 does D or until X+/-Y microseconds have passed")

Or would we want to beat the snot out the database in parallel in a
nondeterministic fashion, and checking for self-consistency and
non-deadlock?

Cheers,

Jeff