Сработает для всех, запросы запустятся в порядке поступления, а ответ придёт как получится (с учётом таймаута для llHTTPRequest). Для связывания запроса и ответа используется ID запроса, в данном примере это
req и
request_id (если совпадают, то это ответ на наш запрос).
Вероятно имеет смысл построить очередь запросов в виде списка, добавлять туда запросы пользователей при поступлении и удалять при обработке. В списке может храниться ID аватара, ID запроса (для проверки соответствия ответа) и текст запроса.
Но тут есть высокая вероятность столкнуться с тем, что пока мы очищаем очередь в обработчике http_response, в неё попытаются писать из listen. В этом случае имеет смысл вынести логику «слушалки» и «обработчика» в разные скрипты (в пределах одного прима). Это то, что я называл в другом посте «работой на шине».
Выглядит это так, что мы слушаем чат (llListen) но при приёме сообщения не вызываем llHTTPRequest, а транслируем сообщение на «шину» с помощью
llMessageLinked, причём в строку с данными имеет смысл поместить ID аватара, который сделал запрос, как-нибудь так:
llMessageLinked(LINK_THIS, 777, (string) avatar_id + "," + text, NULL_KEY);
В другом скрипте (обработчике) слушаем «шину», в обработчике link_message проверяем, наш ли это канал и вызываем llHTTPRequest, как-нибудь так:
link_message(integer sender_number, integer number, string message, key id)
{
if(number == 777)
{
// превращаем строку в список, разделитель — запятая, см. как объединяли
list message_as_list = llParseString2List(message, [","], []);
// рассчёт идёт с 0, на 0-й позиции ID
string avatar_id = llList2String(message_as_list, 0);
// на 1-й — текст
string text = llList2String(message_as_list, 1);
request_id = llHTTPRequest("http://www.ya.ru",[HTTP_METHOD,"GET"],"")
requests_list += [avatar_id, request_id, text];
}
}
Т.к. скрипты у нас работают асинхронно, а обработчик link_message имеет буфер (не помню точно, но 10 сообщений вроде держит), то мы получаем почти совсем многопоточность.
0
