простой сервер, как реализуются системы обслуживания

только сейчас дошло что то что мне надо не совсем сервер, а скорее клиент_)

Алгоритм работы думается примерно такой как в верхнем коде. Расшифрую его -

после запуска «сервера» сначала передаются некоторые закодированные данные data, затем читаются читается ответ, декодируется и обрабатывается.

в конце каждой итерации запрашивается команда, которая является ф-цией и цель которой - изменить внутреннее окружение сервера

следующая итерация происходит с уже изменённым окружением (или не изменённым). Т.е. всё что нужно для изменения «сервера» - расширить/уменьшить его внутренний список состояний, а управлять ими путём простого присваивания новых значений

а, не не, всё, до меня дошло чего я хочу и как это сделать можно ))

Вы прослушали радиопостановку «Лисперские метания»

а при чём тут лисп. или стоило написать код на к примеру cpp? тогда всё ок?

>а, не не, всё, до меня дошло чего я хочу и как это сделать можно ))

Расскажи хоть, неприлично вопросы без ответов оставлять, когда решение есть. Просто интересно.

решения пока нет, я лишь примерно прикинул какое оно должно быть.

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

define active-comand;
loop:
    { 1.принять данные
      2.обработать принятые данные
      3.на основе обработанных данных отправить ответ
      4.прочитать и удалить команду из active-comand
      5.выполнить эту команду
    } 

я понимаю, что решение не красивое, но я раньше не имел вообще никакого дела с сетями. в принципе когда я запостил сюда, я ожидал что посмотрев на мой бред мне посоветуют материал для изучения))

Что за сервер (или таки клиент?)? Что за данные из сети? Что за ответы он выдает на эти данные? Что за комманды? Они из какого-то другого источника? Нужна ли производительность? Масштабируемость?

костяк приведён листингов выше. Какие данные, команды и прочее без разницы. Серверу просто доступны программы кодирования декодирования, а команды передающиеся в сеть можно и в рантайме писать. Данные передаются в аппаратные порты. С них считывается путём чтения файлов этих портов.

Нужна ли производительность? Масштабируемость?

нет, просто анализ и управления небольшими локальными сетями

Данные передаются в аппаратные порты.

ОМГ, я окончательно перестал понимать, что это должно быть, и в чем вопрос.

/dev/port

вопрос изначальный - как такое принято делать.

вопрос актуальный сейчас - есть цикл, который не прерывается, как параллельно ему запустить код, который работал бы в этом же окружении?

>вопрос актуальный сейчас - есть цикл, который не прерывается, как параллельно ему запустить код, который работал бы в этом же окружении?

make-thread?

а в каком пакете?

т.е. в каком пакете её можно найти)

bordeaux-threads

eager-future

sb-thread (специфично для sbcl), bordeaux-threads (пакет совместимости для нитей)

а есть какой нибудь пример работы с ними? основное что интересует - взаимодействие между ними. пока что приходит в голову глобальные переменные для организации такого взаимодействия.

Во-первых, в лиспе можно запросто обойтись без глобальных переменных, ведь есть замыкания. Во-вторых, в bordeaux-threads предоставлено только два примитива синхронизации: mutex и condition variable. Посмотри http://trac.common-lisp.net/bordeaux-threads/wiki/ApiDocumentation, там в целом все ясно (если знаешь, как работают condition variables).

вопрос актуальный сейчас - есть цикл, который не прерывается, как параллельно ему запустить код, который работал бы в этом же окружении?

Ждать данные в цикле не вечно, а с таймаутом?

dmitry_vk, спасибо

Ждать данные в цикле не вечно, а с таймаутом?

в моей задаче постоянный поток байт, который передаёт управляемая система. Хотя можно просто пропускать часть из них, это позволительно там, но ждать команду от человека, следящего за программой управления, непозволительно долгое занятие

Сделай всё на разных процессах, обмен через cl-zmq: он умеет транспорты, например, tcp и inproc (обмен через shared memory). На халяву получишь решение, которое прозрачно по разным хостам разносится, плюс на одной машине хорошо работает.

обмен через cl-zmq

обмен между программой и управляемой системой?

Сделай всё на разных процессах,

я к этому и склонялся изначально. но каким образом управлять циклом в потоке А из потока Б если в потоке А крутится непрерывный цикл? Пока у меня лишь одна идея -

define *programm* = (lambda () nil)

theard B:{
 loop:{
       wait-input in;
       set *programm* in;
}}

theard A:{
  loop:{
        data-work(read-data);
        funcall *programm*;
}}

Короче, почитайте несколько первых глав трех доступных в сети книжек по erlang-у, и сразу воткнете, что такое сервер, и как он должен работать. :-) Вот реально.

а, ну ссылкой выше описывается как раз механизм lock-variables + conditional-variables, который, как мне кажется, именно то что мне нужно)

а что, можно. приведите пожлста название одной из этих трёх, в которой поменьше про синтаксис и побольше про принципы работы и поменьше букв)