[jvm] Начинаем обсуждать план

[Eugene Sharygin]

Добрый вечер,

Vladislav Ivanishin <vlad at ispras.ru> writes:

> me at makkarpov.ru writes:
>
>> Желательно, но сопряжено с большими трудностями. Затем, что парсер по
>> своей натуре поточный, и было бы очень некрасиво буферизовать все в
>> строке.
>
> Что если использовать пайп?
>
> К примеру, ваш эквивалент функции parse принимает java.io.Reader, внутри
> себя он создаёт pipe и вызывает саму функцию parse (видимо, в
> параллельном треде), передавая ей fdopen(filedes[0]). При этом, конечно,
> он должен будет кормить другой конец пайпа данными, считываемыми из
> Reader'a -- есть лишние перекладывания байтов, зато Java-код увидит
> желанный интерфейс, а QBE останется нетронут.

В этом решении будет та же самая буферизация, только скрытая в ядре.
Кроме того, я не уверен, что выгрузка вызовов QBE в отдельный поток не
усложнит конечный Java-интерфейс.

Я не вижу существенных минусов в использовании `fmemopen(3)'. На мой
взгляд, недостатки от излишней буферизации тут точно не перевешивают
недостатки от внесения в QBE потенциально неапстримабельных изменений.

Альтернативно, можно бы ограничить QBE-интерфейс только вводом/выводом
из файлов, поскольку это самый частый случай. Или предоставить
специализированный интерфейс для работы с файлами, который вместо
буферизованных FILE-потоков передаёт QBE настоящие, привязанные к
соответствующим файловые дескрипторам (или открывает "буфер" при помощи
`mmap(2)'), а в общем случае использовать буферизацию.

Если буферизация очень не нравится и хочется сохранить простой общий
интерфейс, можно посмотреть в сторону использования `fopencookie(3)' из
GNU Libc, но это ограничит переносимость.

Наконец, `FILE*' - это стандартный Си-интерфейс, и должны быть известны
способы его сопряжения с потоками JVM без изменения кода исходной
библиотеки. Думаю, не будет лишним исследовать, как это сопряжение
реализовано в JVM-биндингах для других проектах.

--
Regards,
Eugene Sharygin,
ISP RAS.