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

me at makkarpov.ru me at makkarpov.ru
Wed Mar 14 19:37:09 MSK 2018


Тогда давайте просто свитч в configure сделаем, который при наличии fopencookie использует её, а иначе - многопоточную буферизацию.

Все равно, к слову, буферизация частями лучше, чем буферизация ввода целиком.

14.03.2018, 19:19, "Eugene Sharygin" <eush at ispras.ru>:
> Добрый вечер,
>
> 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.


More information about the jvm mailing list