[PD-dev] odd key object behavior under Linux

[Ivica Ico Bukvic]

In my recent troubleshooting saga dealing with xruns and coll object I
identified one rather odd behavior that apparently stems from the [key]
object.

It all started when I noticed that my threaded version of coll object
tended to freeze Pd at apparently random points. As it turns out, I was
testing its robustness simply by passing a key into a read/write message
and holding the key down to generate a large number of requests per
second and the [key] object at times seemed to spit out (while
autorepeat of the pressed key was taking place) two outputs at the same
time which in turn crashed Pd as threaded coll object did not handle
this gracefully. I've since fixed the coll object but the key behavior
baffles me.

The double redundant output is apparent in both rt and non-rt Pd (on
Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is
the simplest patch to invoke this.

Basically, I am measuring the aforesaid time delta between broadcast
strokes using timer object and printing it out to console.

#N canvas 549 345 383 297 10;
#X obj 162 83 key;
#X obj 162 107 sel 32;
#X text 208 108 space;
#X obj 162 145 timer;
#X obj 162 182 print;
#X connect 0 0 1 0;
#X connect 1 0 3 1;
#X connect 1 0 3 0;
#X connect 3 0 4 0;

So, while certainly the fact that threaded version of coll wasn't
handling gracefully multiple redundant requests at the same time was a
bug (which I am hoping has been fixed now), I am wondering whether the
aforesaid [key] behavior might be a bug as it seems to me that
keystrokes of the same key, even if the key is autorepeating should
never have a time delta of zero. Naturally, one can always put a
speedlim after the [key] object but that might result in a truncated
output of fast typing.

I would greatly appreciate it if others can test this to see if they are
getting the same results.

FWIW, allowing this kind of key behavior in more complex patches did
result in the pd<->gui communication tearing with the stderr reporting
several truncated messages before crashing. Due to their complexity and
unpredictability of a point where tearing would occur I am not sure
where the problem might be stemming from but it is undoubtedly at least
in part instigated by double redundant output from the key object
possibly in conjunction with objects that may have not provided graceful
handling of such requests.

NB: I only tested the same patch on Win platform and there it does not
exhibit this problem.

Any thoughts would be most appreciated.

Best wishes,

Ico