Вчера на ночь сделал так. В основном приложении очередь, точнее две копии, на основе пользовательского класса, ("родная" очередь в D2006 оказалась неудобной, т.к. ее реализация старая, работает только с указателями, много лишних телодвижений ), которые заполняются синхронно при поступлении данных по каналам TCP и RS-232. В первой очереди хранится имя процедуры внутри PSScript, во второй - собственно сами данные, предназначенные для обработки этой процедурой. Занесение элементов в очереди сделано так:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
procedure TForm3.Add_to_Queue(Function_Name_To_Get_Input_Data: String; Data_String: String); // Помещение в очередь
Begin
Try
CriticalSection.Enter;
Function_Name_Queue.Enqueue(Function_Name_To_Get_Input_Data);
Data_String_Queue.Enqueue(Data_String);
Finally
CriticalSection.Leave;
End;
End;
Разумеется, Add_to_Queue вызывается из разныйх мест - сейчас по приходу данных по каналу TCP и по RS-232. Вопрос - так до сих пор и не нашел однозначного ответа, если код в критической секции занят, другой запрос просто отбрасывается, и повторные попытки нужно оформлять самостоятельно, или из другого потока запрос на выполнение процедуры будет выпонен автоматически, с определенным числом попыток например?
Выборка из очереди производится внутри самодельного таймера с интервалом 10 миллисекунд, на основе MMSystem.
Внутри таймера:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
procedure TimerProc(uTimerID, uMessage: UINT; dwUser, dw1, dw2: DWORD) stdcall; // Обработка очереди
begin
If PS_IS_Ready='No' Then Exit; // Флаг доступный процедурам PS. Означает, что сейчас выполняется та или иная процеура внутри PS
If Function_Name_Queue.isEmpty Then Exit;
PS_IS_Ready:='No'; // Устанавливаем флаг
Form3.Call_PS_Function(Function_Name_Queue.Dequeue, Data_String_Queue.Dequeue, '', ''); // Вызываем процедуру обработки внутри скрипта
end;
сразу выставляется в доступной и для PSScript внешней переменной - PS_IS_Ready:='No'. Внутри обрабатывающих процедур, уже в PSScript, при окончании работы процедуры ставится PS_IS_Ready:='Yes'
Код отработал несколько часов, данные от прибора поступали со скоростью 115200 по RS-232 десять раз в секунду. Посылки около 64 байт. Число посылок от прибора и на него - по 233 тысячи. При этом по TCP тоже были редкие посылки, до 300 примерно за все время, которые также были корректно обработаны соотв. процедурой внутри скрипта.
Все вроде отработало, но есть ощущение, что что-то сделано не правильно, нужно как-то по другомую. Буду рад любым замечаниям.
Создавать экземпляр PSScript отдельного потока здесь пожалуй не получится - кто знает, как пользователь будет писать свою программу и какие общие переменные захочет использовать внутри скрипта. Прокидывать в PSScript или как-то создавать динамически во внешнем приложении заранее не извесное число переменных неизвестно какого типа - велосипед будет тот еще. Хотелось бы, что бы пользователь скрипта писал с минимальными понятиями о том, как это все снаружи устроено.
Да, заметил еще такую вещь. Внутри скрипта есть еще отдельная процедура, которая никак пока не оформлена флагами. Она (сейчас по крайней мере) может быть вызвана не из очереди, а сама по себе. Эта процедура оправляет данные по TCP, дергая в свою очередь нужную процедуру в основном приложении. При этом, как будто ошибок не возникает. У меня вообще такое ощущение, что в данной ситуации PSScript "сам" приостанавливает выполнение текущей процедуры, например по обработке данных от RS-232, а потом возвращается к ней автоматически. Что-то вроде стека. Глюк это или приятная фича - пока не понятно. Если нам нужно как можно быстрее отправить команду на включение света, например, и посылка по TCP уйдет на умное реле, на долю секунды приостановив работу других процедур, то это не страшно. Но если при этом, при частом использовании, вылезут побочные эффекты и потребуется ввседение очереди уже и внутри PSScript, то это будет грустно. Время реакции может колебаться в непредсказуемых пределах!
