LINUX.ORG.RU
Форум — Development  

хочу писать библиотеку с состояниями


0

0

Собственно сабж в целях коммуникации. Всё усугубляется необходимостью:

a) не блокироваться на неопределённое время;

б) иметь разумное время реакции на сообщения поступающие по коммуникационному интерфейсу (socket или terminal), вообще подразумевается, что это возможно...;

в) работа совместно с циклом обработки событий Windows, GTK, Tk, что угодно ещё...

Подразумевается, что внешнее по отношению к моему поделию ПО оное поделие использует. Цикл обработки событий реализован в этом самом ПО. Вопрос: каким образом можно обеспечить пункт Б.

По идейным, религиозным и прочим другим убеждениям я выступаю против мультипоточности. И асинхронных сигналов в ОС виндовс не предусмотрено.

Варианты:

1. библиотека отдаёт file handle(s) и указатели функций обработчиков для обработки событий внешней программой.

2. ? (периодически опрос -- явно плохой вариант).

3. вынести всё в отдельный процесс, связать с собственно библиотечной частью через pipe, например, где ни блокировка не возникает, ни наоборот, время реакции не имеет значения.

Может быть существуют типовые решения?

★
← emacs - *-rectangle
Адекватная замена элипсисам (...) в C++ →

> работа совместно с циклом обработки событий Windows, GTK, Tk, что угодно ещё...

Охренел, да? Мухи отдельно, котлеты отдельно! GUI вообще надо не просто отдельной ниткой крутить, но и вообще отдельным процессом. И общаться с ним через сокеты.

> я выступаю против мультипоточности.

Дурак. Но тогда тем более - fork - твой путь.

> Может быть существуют типовые решения?

Да, конечно же. select() -> очередь сообщений -> обработка сообщений. Причём оно совершенно одинаково реализуется как в однопоточном варианте, так и в многопоточном. Все блокировки ныкаются внутри реализации очереди сообщений, обработчикам до этого должно быть похрену.

Balabol
()
Ответ на: комментарий от Balabol

>> работа совместно с циклом обработки событий Windows, GTK, Tk, что угодно ещё...

>Охренел, да? Мухи отдельно, котлеты отдельно! GUI вообще надо не просто отдельной ниткой крутить, но и вообще отдельным процессом. И общаться с ним через сокеты.

В том-то и дело. Как ты мух от котлет не отделяй, что-то между ними посередине будет. В данном случае именно про ту часть речь и идёт. А мухи сами по себе давно и успешно летают не то что в отдельной нити -- на отдельном процессоре и в отдельном приборе. И состояние котлет им глубоко не важно. А вот обратное не верно.

fork() в виндовс называется exec(). Но не в том суть, так нужно ещё один уровень писать -- см. абзац выше. Рекурсия.

select() это понятно. Но это вынуждает клиента обрабатываеть мои события, а я не уверен, что он это достаточно легко может.

fk0 ★
() автор топика
Ответ на: комментарий от fk0

> Но это вынуждает клиента обрабатываеть мои события, а я не уверен, что он это достаточно легко может.

О каких событиях говоришь?

Balabol
()
Ответ на: комментарий от fk0

fk0

> Как ты мух от котлет не отделяй, что-то между ними посередине будет. В данном случае именно про ту часть речь и идёт.

Как раз _такие_ части и не могут быть написаны системонезависимым образом. Придется отдельно для Вындовса, отдельно для Юникса (а часто даже для Соляриса/Линукса/Ирикса/БСД/etc...)

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

> Как раз _такие_ части и не могут быть написаны системонезависимым образом. Придется отдельно для Вындовса, отдельно для Юникса (а часто даже для Соляриса/Линукса/Ирикса/БСД/etc...)

Речь не про то как написать, с точки зрения кодирования -- это очевидно.

Речь про то КАК писать. С точки зрения интерфейса.

fk0 ★
() автор топика 

посмотрте как реализован цикл обработки событий в tcl/tk;

насколько понимаю это ближайший (к тому-же полный и системо-независимый) аналог того,
что Вы хотите сделать.

Особенно обратите внимание на то как встраивается tk event-loop.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← emacs - *-rectangle
Development
Адекватная замена элипсисам (...) в C++ →