Igenigen, ezutobbi valtozat is mukodik, kiprobaltam :)
/mnt/tmp/apal$ ipf -f xyz.json.gz -p 'gzip -d | xz' -d queue-dir -s $((1*1024*1024))
/mnt/tmp/apal$ mv xyz.json.gz xyz.json.xz
/mnt/tmp/apal$ xzcat xyz.json.xz | md5sum
5e3d2a0e966b4f8536c81f7212756cfd -
Szoval a `middle-fifo`-t meg szepen letrehozza a (ba)sh, ahogy kell!
Most az akademiaibb problemam -- ebben az "ipf hozza letre a gyerekprocesszt" temaban -- inkabb az hogy hogyan lehet megkulonboztetni azt az esetet hogy a "child processz nem birt egy exec*() valamit elinditani" attol az esettol hogy "a child processz elindult es szabalyosan egy 0 hosszu stream-et hozott letre majd zart le". Nyilvan valami olyasmi lehet jo hogy a "pipe read oldala azelott bezarodott hogy a write oldalba barmit is irtunk volna", de ez ugye meg race condition es/vagy timing problema.
Igen, a signal-os dolgokat jobban at kell neznem hogy igy hogy is vannak itt az `ipf`-ben pontosan. Az az amit nagyon-nagyon kerulok ugy altalaban - azaz ha valamit meg lehet oldani 100 sorbol szinkron multiplexinggel es 10 sorbol signal-okkal, akkor is inkabb ezelobbit valasztom. Oke, szelsoseges a pelda... De inkabb ezelobbi, es akkor akkora meglepetes nem erhet minket. Bar itt ebben a peccsben fork() utan van a signal-ok letrehozasa, szoval elvileg a gyerek semmit nem lat abbol:
if ( process_filter != NULL )
{ if ( (pf_pid=open_process(process_filter,&orig_fifo,&filtered_fifo))<=0 )
goto free_buf_tmp;
}
else
{ if (!open_file_and_check_type(&orig_fifo, O_WRONLY, false)) {
goto close_regf;
}
if (!open_file_and_check_type(&filtered_fifo, O_RDONLY, false)) {
goto close_orig_fifo;
}
pf_pid=0;
}
if (!signals_setup(&orig_actions, &orig_mask)) {
goto close_filtered_fifo;
}