народ что вы думаете по этому поводу?
буду рад если вы пришлете ссылки на статьи, ресурсы….
народ что вы думаете по этому поводу?
буду рад если вы пришлете ссылки на статьи, ресурсы….
Клуб программистов работает уже ой-ой-ой сколько, а если поточнее, то с 2007 года.
5 декабря 2007 в 11:03
Кгм, по-моему проще все-таки сокетами, не находишь?
5 декабря 2007 в 2:05
конечно можно,
наверно это даже правильнее, потому что могут быть ещё какие-то третьи процессы, например, юзер с шаловливыми ручонками залезет…
хотя, если нормально обрабатывать ошибки открытия файла, то это не проблема
просто мне лично больше нравится пользоваться объектами для синхронизации, когда такие простые случаи
блокировки файлов в основном сделаны для того, чтоб отдельныекусочки "защищать"
ну, например, если доступ к какой-то структуре или базе данных внутри файла надо организовать, или что-то подобное
только тут для режима с ожиданием придётся вручную цикл делать, который будет пытаться блокировать, а не как с семафором
ну а если мы предпочтём вариант без ожидания – то да, всё просто
5 декабря 2007 в 0:04
А разве нельзя то же самое сделать блокировкой файла?
4 декабря 2007 в 23:05
всем спасибо…я в ринципе понял…(по крайней мере какие механизмы для этого изучить)
данный вопрос считаю актуальным… поэтому если найдёте чёньть интересное..пишите
4 декабря 2007 в 4:00
Признаю, сказал неправильно. Следует сказать "объектами синхронизации", точнее, одним объектом. Смысл тут в чём. Это нужно, если клиент и сервер работают асинхронно. А скорее всего, это так и будет, поскольку у тебя там какие-то суперсложные вычисления, и делать их на каждое обновление клиентского представления, насколько я понимаю, "слишком жирно". Итак, сервер постоянно обсчитывает модель и складывает её состояние в файл, создаёт такой "дамп", открывая каждый раз файл по записи и с усечением старого содержимого. Одновременно с этим, периодически с клиента по какому-нибудь AJAX Updater-у приходят запросы на данные модели, чтобы отобразить изменения на страничке. Скрипт, обрабатывающий запрос, должен открыть этот же файл для чтения, и возможно, это ему удастся (а может и нет, в зависимости от режима открытия тем, кто пишет). Проблема же заключается в том, что когда клиенту понадобятся данные, файл может находиться в "кривом" состоянии, поскольку процесс записи ещё не завершился.Получается фигня. Чтобы фигни не было, вводится объект синхронизации (mutex). Пишущий процесс непосредственно перед записью блокирует mutex, после записи – разблокирует его, отмечая тем самым период времени, когда доступа к файлу для кого-то другого быть не должно. Вычитывающий процесс пытается блокировать этот же mutex перед чтением из файла, иесли вдруг идёт запись, у него это естественно не получается, так как mutex заблокирован тем, кто пишет. В этом случае есть два варианта: либо "отвалить", передав на клиент признак того, что данные пока не доступны, либо – "встать"и подождать, пока ресурс освободится (на самом деле, есть и третий, промежочный: "отвалить" по таймауту). Мне больше нравится первый вариант, поскольку у нас всё равно организован этот periodical update, хотя второй вариант более "классический" – постоять на семафоре. Ну вот, а когда читающий процесс всё же получит возможность заблокировать mutex, он его резко блокирует, и уже пишущий тогда не сможет получить доступ для записи, пока читатель не "отпустит" mutex, и это правильно – нечего портить файл, тут люди вообще-то читают его. Так вот они и работают дружно в паре, писатель и читатель, и друг друга культурно "притормаживают", если случайно сталкиваются. Название MutEx так и расшифровывается – mutual exclusion, взаимное исключение. Хотя, может ты это и так знаешь.
4 декабря 2007 в 0:03
2Дмитрий: хорошая идея…ток пожалй лучше в XML формате (в данном случае это принципиально…поскольку данные разного рода)
только я не очень понял по поводу: "…сигналами это дело синхронизировать"
4 декабря 2007 в 0:02
клиент задаёт параметры… отправляет на сервер…
в режиме реального времени приходят данные (например, распределение потенциала от расстояния до источника)…ну здесь уже Ajax..
в некотором смысле должна получится некая виртуальная лаборатория
вот!!!
4 декабря 2007 в 0:02
по мере вычисления данных , они должны непрерывным потоком…или хотя бы порциями поступать на клиентскую машину
3 декабря 2007 в 23:02
если имеется непрерывная генерация результатов, то пусть модель складывает результаты в бд (пусть даже текстовичок), а php-скрипт берет хвост файла нужной длины и отдает браузеру
если же модель обсчитывает сразу и выдает результаты, то поможет cgi (главное, чтобы модель могла писать и читать из стандартных потоков stdin и stdout)
3 декабря 2007 в 23:01
Ну сокеты, а можно наверно даже в файл складывать?
Вот так тупо. Ну и сигналами это дело синхронизировать. Я не очень понял, там есть какой-то бесконечный цикл вычислений что ли? Или так: поменяли параметры модели, послали на сервер, хотим увидеть результат?
3 декабря 2007 в 20:05
Вообще да, согласен, DLL имеет отношение к IPC.
3 декабря 2007 в 20:02
DLL – динамически загружаемые библиотеки, прекрасный инструмент межъязыкового взаимодействия на платформе Windows. Для всех языков, которые понимают конвенцию stdcall и простые типы данных.
3 декабря 2007 в 19:02
Причем тут DLL?
3 декабря 2007 в 18:00
В конце-то концов, DLL, COM, TCP/IP.
3 декабря 2007 в 17:04
Пусть твоя PHP-программа общается с C++ной или фортранной через сокеты, например – это имхо самый простой и быстрый способ коммуникации двух процессов на одной машине. В каком формате будешь по этим сокетам данные гонять – дело твое; хоть в XML, тут проблемы в скорости скорее всего не будет.
Получится так: на машине-сервере есть вычислительный сервер А и сервер представления B. Наружу виден только B. B обращается к А за вычислениями, а результат выдает наружу.
3 декабря 2007 в 17:04
Отличается от JVM тем, что она не для Java и тесно интергрирована в нашу СУБД, а с недавнего времени мы её выделили в отдельный модуль и тянем везде, где можно. Нам так удобно. Не знаю, насколько это принципиальное отличие, да наверно нет, просто, Java было не очень удобно для наших задач. Не секрет, мы пишем Кодекс. Это такая база различных документов, изначально правовых, но не обязательно. У нас, кстати, текстовый индекстоже хорошо представлен, мы участвуем в РОМИП, например, как и Яндекс, насколько я знаю.
3 декабря 2007 в 17:02
вобщем суть задачи такова:
1)на fortran'е или на С++ пишу некую физическую модель (если угодно в MatLab'е)… то есть так называемое вычислительное ядро
2) интерфейс представления полученных данных пишу на PHP..
3) теперь, непосредствено, хочу передать данные с потока вычислительного ядра на поток интерфейса представления… (вот здесь и возникает проблема … НЕЗНАЮ КАК!!!!)
иными словами есть клиентская машина и есть сервер… все вычисления производятся на сервере, а по запросу клиента присылаются данные.. в принципе могу приладить движок Ajax'а… ну это уже навороты… не суть важно
В любом случае спасибо!!!
3 декабря 2007 в 17:02
хотел использовать XML, но боюсь PHP захлебнётся с мегобайтными данными (время отклика для клиента будет существенно большим)….
если можно, пришлите ссылки на практические примеры….или хотя бы на книги
3 декабря 2007 в 12:01
Дмитрий, а зачем вам понадобилась своя платформа? Чем она принципиально отличается от JVM, к примеру; на что она заточена? Что вы вообще разрабатываете, если не секрет?
3 декабря 2007 в 10:02
Ну какие GPL, все права на код принадлежат конторе.
3 декабря 2007 в 3:03
Занятно. А технология закрыта? Под GPL не публикуете?)
3 декабря 2007 в 1:01
сами всё
3 декабря 2007 в 0:00
Своя VM и свои скрипты в смысле сами всё писали? Или адаптировали растпространённые варианты типа JRuby и Groovy?
2 декабря 2007 в 21:01
Ну например распространена схема, когда делаютсякомпоненты на одном языке (например, С/С++), а высокоуовневая логика – на т. н. языке склейкиglue/scripting language (ECMA Script, Perl, Ruby, и т.д.) Примеры: всяческие СУБД, те же браузеры. Это работает, и это хорошо: это побуждает делать компоненты с чётким интерфейсом для скриптов, что хорошо для дизайна; введение скриптов уменьшает необходимость перекомпилировать всё приложение (если до этого оно было целиком на компилируемом языке)- скорость разработки растёт. Тема эта достаточно широка. Вот, например, про скрипты: //en.wikipedia.org/wiki/Scripting_language. Сам работаю в конторе, где есть своя "платформа", своя VM, свои скрипты, могу сказать, что получается очень здОрово.
2 декабря 2007 в 17:05
По этому поводу я думаю, что оно возможно. Скажи поконкретней, что тебя интересует. Тебя интересуют совсем общие концепции, или то, как это реализуется между конкретной парой языков (каких?)?
2 декабря 2007 в 17:04
Тебя интересуют FFI (Foreign function interface), архитектуры вроде RPC, CORBA, SOAP и, наверное, среды вроде CLR. Можешь начать, например, отсюда //en.wikipedia.org/wiki/Foreign_function_interface