table.s*

напишите себе тест: из одного потока забиваем таблицу миллионом цифр посредством sinsert. из другого потока удаляем по одному элементу посредством sremove. ну и попробуйте дождаться окончания процесса.

по результатам оторвите руки написавшему эти функции и ноги тому, кто рекомендовал их использовать для обмена данными между потоками терминала и скрипта.

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

сомневаюсь, что они ВООБЩЕ Вам ответят на данный вопрос. Если Вы игнорируете пользователей то, спрашивается, - что Вы здесь забыли? Это именно то место - где каждый может задать вопрос каждому. Если Вас это не устраивает - Вы можете воспользоваться электронной почтой или личкой....

Михаил.

Естественно что для обмена между потоком терминала и потоком скрипта нам требуется очередь FIFO. Поэтому при использовании table.s есть 2 варианта.
1. Добавлять данные в хвост таблицы (быстро) и удалять первое значение (медленно)
2. Добавлять в начало таблицы (медленно) и убирать  последнее значение (быстро)

Хрен редьки не слаще.

Теста у меня уже нет, удалил. писать там особо нечего  сначала в цикле добавляем через sinsert миллион строк, после чего в цикле удаляем первое значение по sremove.

на моем компьютере за секунду удалялось 10 значений (каждую секунду). я подождал минут 5 и понял, что ждать дальше смысла нет. Предположений два: либо размеряются какие-то временнЫе промежутки, равные 1/10 секунды, либо перелопачивание всего массива функцией sremove несет огромные расходы.

И в том и другом случае - на помойку. Заменил на собственную функцию с тем же интерфейсом - проблемы исчезли.

миллион значений - вполне нормальная ситуация из реальной задачи.

а если использовать b-tree?