evbtagger | glom pipe fails to write end run item to final output

[aschester]

A bit of detail and context here: I write Pixie-Net binary data files with the Pixie-16 data format. These files are converted to NSCLDAQ .evt files by wrapping up the XIA data in a PHYSICS_EVENT ring item with the appropriate header info and writing to a file sink. A start item is written prior to any of the physics items and an end run is written after the final physics item has been seen. The presence of the state change items after the initial conversion from binary to evt can be verified by pointing the dumper at the output and excluding physics items.

To build events a simple pipe was constructed (leaving out the args for brevity): cat | evbtagger | glom > out. One can verify the presense of the state change items in the evbtagger output by looking at the last ~few hundred bytes of a hexdump of cat | evbtagger > out (cant dump these files). The end run item is seen by glom (verified by modifying glom to report that its seen an end) but the end run is not written by glom to the final output.

The pipe cat | stdintoring | ringtostdout | evbtagger | glom > out does write the end run item even though there should be no difference between the two methods.

[rfoxkendo]

Going to try to make a test that reproducdes this...it smells of buffers -> GLom not being flushed or some timing in thye way the pipe is broken down. ..or maybe need to catch SIGPIPE and ignore it in Glom(?)

[rfoxkendo]

Hypothesis... glom does not ignore SIGPIPE - that means that when the sender clsoes the pipe SIGPIPE Is delivered and the default action is to terminate. IF that signal is delivered (asynchronously) before glom has a chancde to figure out how to deal with and actually write the END_RUN ring item, this behavior could occur. The reason we don't see this online is that We leave the event building pipeline up until the next run starts (if we restart it at all), so all has run down nicely. I think the reason the pipeline with a ring in the middle works is the ring buffer in the middle.

[rfoxkendo]

Previous commit should make glom ignore SIGPIPE

[rfoxkendo]

Also turn off sigpipe in evbtagger

[aschester]

I tested with the cat | evbtagger | glom pipe without using any ringbuffers. The end run is still not written to the built event file.

[rfoxkendo]

Commit above fixes this and an error in evts2frags that can result only with pipe input - specifically depending on the timing, the block reader could read a very small number of bytes when data were ready rather than reading the requested amount.