[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