Неблокиращ FIFO: откриване дали съществува четец?

Създадох FIFO, където мога да правя неблокиращи записи по този начин:

// others, searching for a non-blocking FIFO-writer may copy this ;-)
mkfifo("/tmp/myfifo", S_IRWXU);
int fifo_fd = open("/tmp/myfifo", O_RDWR);
fcntl(fifo_fd, F_SETFL, fcntl(fifo_fd, F_GETFL) | O_NONBLOCK);

// and then in a loop:
LOGI("Writing into fifo.");
if (write(fifo_fd, data, count) < 0) {
    LOGE("Failed to write into fifo: %s", strerror(errno));
}

Неблокиращият запис работи перфектно.

От друга страна, отварям FIFO за четене и правя същото fcntl(), за да направя read() неблокиращ.

Сега бих искал да направя няколко (интензивни процесора) изчисления от страна на запис, но САМО ако има прикачен четец.

Поради това трябва да намеря начин от страната на запис, за да открия дали FIFO е отворен за четене някъде другаде.

Някой има ли идея как да се постигне това?


c nonblocking fifo
person Martin L.    schedule 28.01.2013    source източник
comment
Заглавието ви казва писател, въпросът ви казва читател...   -  person Oliver Charlesworth    schedule 28.01.2013
comment
@Oli ..И кодът казва O_RDWR (между другото не е POSIX)   -  person Anton Kovalenko    schedule 28.01.2013
comment
› В заглавието ви пише писател.. о, да, благодаря ви.   -  person Martin L.    schedule 28.01.2013
comment
Защо не направите open("fifo", O_WRONLY | O_NONBLOCK)? Това ще се провали с ENXIO, ако няма четци.   -  person melpomene    schedule 28.01.2013
comment
Тъй като процесът на писане трябва да бъде абсолютно независим от четец, но четецът трябва да може да се прикачва във всички моменти (разбирайте четеца като допълнителен монитор). Тогава това ще е възможно само ако направя open() и close() в цикъла за запис. Колко (не)ефективно ще бъде това? Може би е по-малко вредно, отколкото си мислех?   -  person Martin L.    schedule 28.01.2013
comment
Е, просто опитайте и измерете. Най-важната част е, че четец може да се появи във всеки момент, след като проверите и установите, че няма четци. Добре ли е читателят да блокира веднъж, дори ако писателят може да го захрани, ако знае, че трябва?   -  person Anton Kovalenko    schedule 28.01.2013
comment
Сега опитах това - изглежда, че няма проблем с производителността. НО: Тъй като правя отваряне и затваряне в цикъла, симулираният четец cat /tmp/myfifo се затваря веднага след 1 двупосочно пътуване (авторът затваря -› котката си мисли, о, готово). Жалко, това изглежда не е правилният начин.   -  person Martin L.    schedule 28.01.2013

Отговори (1)


arrow_upward
0
arrow_downward

Сега бих искал да направя няколко (интензивни процесора) изчисления от страна на запис, но САМО ако има прикачен четец.

За това можете просто да създадете сокет и когато потребител се свърже с него, да свършите работа и да пишете обратно.
Но мисля, че по-добро решение е резултатите от изчисленията да са готови за потребителите, преди да се свържат (или да отворят FIFO). но не искате производителят да работи, ако работата не се консумира. Така че дефинирайте N, брой работни резултати, които сте готови да запазите достъпни за потребление и оставете производителя (или производителите) да работят и записват резултатите в опашка с размер N, докато не се запълни.
Можете да приложите това с нишки, една нишката слуша за връзки, изскача от опашката и пише на потребителя и една или повече нишки на производителя, работещи и натискащи към опашката.
Или можете да използвате опашки за POSIX съобщения, за да се избегнат главоболия с нишки. Създайте опашка с размер N, независими производители (множество процеси, написани на различни езици) могат да натискат опашката, докато се запълни, и множество независими потребители изскачат от нея.

person bahaa    schedule 29.01.2013
comment
Благодаря Ви за отговора. Опашките за съобщения на POSIX са наистина интересни. Но моето решение сега беше, че клиентът създава малък контролен файл, който се проверява от работника чрез access(..). Изчислението се прави само ако съществува поне един управляващ файл. - person Martin L.; 30.01.2013