LINUX.ORG.RU

Cloudflare выпустила первый публичный релиз Pingora v0.1.0

 ,

Cloudflare выпустила первый публичный релиз Pingora v0.1.0

0

4

5 апреля 2024 года Cloudflare представила первый публичный релиз открытого проекта Pingora v0.1.0 (уже v0.1.1). Это асинхронный многопоточный фреймворк на Rust, который помогает создавать прокси-сервисы HTTP. Проект используется для создания сервисов, обеспечивающих значительную часть трафика в Cloudflare (вместо применения Nginx). Исходный код Pingora опубликован на GitHub под лицензией Apache 2.0.

Pingora предоставляет библиотеки и API для создания сервисов поверх HTTP/1 и HTTP/2, TLS или просто TCP/UDP. В качестве прокси-сервера он поддерживает сквозное проксирование HTTP/1 и HTTP/2, gRPC и WebSocket. Поддержка HTTP/3 — в планах. Pingora также включает в себя настраиваемые стратегии балансировки нагрузки и аварийного переключения. Чтобы соответствовать требованиям и безопасности, он поддерживает как широко используемые библиотеки OpenSSL, так и BoringSSL, которые соответствуют требованиям FIPS (федеральных стандартов обработки информации США) и пост-квантового шифрования.

Помимо этих функций, Pingora предоставляет фильтры и обратные вызовы, позволяющие пользователям полностью настраивать то, как сервис должен обрабатывать, преобразовывать и пересылать запросы.

В рабочем режиме Pingora обеспечивает плавный перезапуск без простоев для самостоятельного обновления, не теряя ни одного входящего запроса. Syslog, Prometheus, Sentry, OpenTelemetry и другие необходимые инструменты наблюдения легко интегрируются с Pingora.

Возможности Pingora: использование Async Rust, поддержка HTTP 1/2 end to end proxy, TLS over OpenSSL или BoringSSL, gRPC и проксирование веб-сокетов, Graceful reload, настраиваемые стратегии балансировки нагрузки и аварийного переключения, поддержка различных инструментов мониторинга.

В версии Pingora v0.1.1 исправлены ранее обнаруженные ошибки, улучшена производительность алгоритма pingora-ketama, добавлено больше бенчмарков TinyUFO и тестов для pingora-cache purge, ограничен размер буфера для журналов ошибок InvalidHTTPHeader, а также исправлены опечатки и внесены необходимые исправления в комментариях и документации проекта.

>>> Подробности

★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)

Ответ на: комментарий от zx_gamer

Если человек программист, а не чайник, то ему даже в голову не придёт сохранять указатель на объект, который уничтожится после выхода их скоупа.

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

В С++ узнать допустимо ли передавать в функцию объект на стеке можно из документации, просмотрев вручную ее код или при помощи стороннего анализатора кода.

Документация может отставать от кода, ручной анализ это потеря времени и возможность ошибки, автоматические анализаторы С++ неидеальны и могут пропускать проблемы или показывать ложные срабатывания.

No
()
Ответ на: комментарий от No

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

zx_gamer ★★
()
Ответ на: комментарий от mx__

Это не важно, язык запрещает работать с тем чего нет. Но вот вам вариант с указателем

use std::cell::RefCell;



fn main() {
    // это во время компиляции проверяется
    let mut arr = Box::new([' ';100]);
    //let mut  arr:Box<['';100]>; - так работать не будет
    arr[99]='b';
    println!("{:?}",arr);
    // это рантайм
    let mut arr = RefCell::new([' ';100]);
    //let mut arr: RefCell<[char;100]>; так не скомпилируется
    arr.get_mut()[99]='b';
    println!("{:?}",arr);
   
}

Silerus ★★★★
()
Последнее исправление: Silerus (всего исправлений: 1)
Ответ на: комментарий от Silerus

Я тут почитал инет про Rust и:

С помощью операции разыменования (операция *) можно обратиться к значению по адресу, который хранится в указателе. Однако это обращение должно производиться в блоке unsafe:

;) Все расходимся, могли бы сразу про это написать.

mx__ ★★★★★
()
Ответ на: комментарий от zx_gamer

В новых «стандартах» языка Си смысла просто нет.

Конечно есть, они частично основаны на наиболее используемых расширениях gcc. Вкуснее только -std=gnu17.

Очень много программистов кладут с прибором на C после C89 и ИМХО правильно делают.

Самые используемые проекты на С не кладут.

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от Silerus

Опять стоп. Я сейчас внимательнее посмотрел на тот кусок си, там тоже нет указателей, (блин я подумал что это про адреса когда писали про разное) и поскольку у меня тот кусок всегда выдает одинаковый результат то дождемся в начале куска с разными результатами от Си, проверим его, а уж потом за Rust возьмемся.

mx__ ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Самые используемые проекты на С не кладут.

Это камень в сторону ядра что ли ?

mx__ ★★★★★
()
Ответ на: комментарий от MOPKOBKA

передаешь ты структуру куда то, на обработку дополнительную

ну и передавай шареную ссылку, или ты текстуру по ходу игры изменять собрался? Ну тогда передавай уникальную ссылку. Счетчик ссылок тебе здесь вообще зачем? Вот если тебе надо кеш этих текстур хранить, тогда да.

FishHook
()
Ответ на: комментарий от FishHook

ну и передавай шареную ссылку

Если не использовать счетчик, и любым образом вытянуть поинтер на структуру, то возможно обращение к ней после освобождения, потому что я могу ее передать в другой поток, там поставится задача в очередь, но когда до нее дойдет, игра уже освободит текстуру.

Счетчик ссылок тебе здесь вообще зачем?

Есть текстуры, их могут использовать множество сущностей, вроде все понятно.

Вот если тебе надо кеш этих текстур хранить, тогда да.

Да, я говорю про неэффективную реализацию кеша.

MOPKOBKA ★★★★
()
Ответ на: комментарий от mx__

Смысл того ub в чем - там идет создание массива без инициализации - просто выделяется адресное пространство. Там могут быть старые данные, могут не быть, на некоторых ядрах (это вроде про cgroup) - память может принудительно инициироваться 0. Потому обращаясь к памяти - мы не знаем что получим на выводе от случая к случаю.

Silerus ★★★★
()
Ответ на: комментарий от Qui-Gon

общая суть претензий расто-хипстеров сводится к тому что на сишечке и плюсах можно сделать немного больше чем все

Ты под чем-то, скажи честно? Долбите на пару с @mx__? Вам сколько раз уже объяснили, что программистские проблемы не в языке, а в алгоритмической сложности, и области знаний? Что CVE возникают не на пустом месте?

Как об стенку горохом - продолжаете нести свой бред про неумелые руки и заговоры для замены всех индусами.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от unC0Rr

На основании того, что это такой же упертый Шариков, как и приснопамятный метапрог. Не знает, но мнение имеет. А после того, как ему разжевали и в рот положили, он покивал и опять начал нести свою ерунду.

liksys ★★★★
()
Ответ на: комментарий от Silerus

Ну это скорее к ос уже вопросы. Опять читать из куска в который еще ничего не писал это уже вопрос к кодеру …

Кстати все таки будет для начала такой пример для си ? Интересно даже.

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 1)
Ответ на: комментарий от zx_gamer

В новых «стандартах» языка Си смысла просто нет. Они не дают новых возможностей, зато ломают старый код.

А ты их читал вообще, или теоретизируешь, как обычно?

Из постоянно используемого, например, очень полезен stdatomic.

liksys ★★★★
()
Ответ на: комментарий от mx__

Это именно вопрос к программистам и языку, из-за этого есть ядра типа hardned. Именно по этому есть рекомендация, на грани приказа, для с/с++ - при создание переменной/указателя, они должны быть сразу инициализированы 0/NULL/nullptr, для этого с 14 (вроде с 14) стандарта, появилась инициализация фигурными и квадратными скобочками.

Silerus ★★★★
()
Ответ на: комментарий от monk

Там и так есть extern, сработает где бы функция не находилась.

MOPKOBKA ★★★★
()
Ответ на: комментарий от MOPKOBKA

Самые используемые проекты на С не кладут.

Ну посмотрите, например, на SQLite3.

Конечно есть, они частично основаны на наиболее используемых расширениях gcc. Вкуснее только -std=gnu17.

Если вам так кажется, то скорее всего вы никогда не программировали на Си. Точнее, вы программировали на каком-то языке, имеющим мало общего с Си.

zx_gamer ★★
()
Ответ на: комментарий от zx_gamer

Ну посмотрите, например, на SQLite3.

Посмотрел, все собирают без флагов указывающих на древний стандарт, те используют c99 для ее сборки, и не используют c89.

MOPKOBKA ★★★★
()
Ответ на: комментарий от liksys

Из постоянно используемого, например, очень полезен stdatomic.

Как все плохо. Ну даже допустим действительно нужна многопоточность. Нафига этот недоогрызок? Что мешает взять обычный POSIX threads и не страдать фигней? К тому же, он в итоге использует его, только ограничивает функционал и заворачивает в бесполезные обертки.

Я могу представить, где многопоточность может быть нужна. Но расскажите, пожалуйста, в какой задаче вы хотите ее применять?

zx_gamer ★★
()
Ответ на: комментарий от MOPKOBKA

Код написан в ANSI С и соберется любым компилятором.

И нет, это не «древний» стандарт. «Древний» это K&R.

zx_gamer ★★
()
Ответ на: комментарий от zx_gamer

Как все плохо.

Всё очень хорошо.

Нафига этот недоогрызок? Что мешает взять обычный POSIX threads и не страдать фигней?

Я не вижу в посиксе атомарных переменных. Не подскажешь, где они?

он в итоге использует его

Стандарт не регламентирует это. По возможности будут использоваться инструкции процессора, гарантирующие атомарный доступ.

Но расскажите, пожалуйста, в какой задаче вы хотите ее применять?

В любой задаче, где нужна параллельная обработка с общими ресурсами.

liksys ★★★★
()
Ответ на: комментарий от liksys

В любой задаче, где нужна параллельная обработка с общими ресурсами.

А, собственно, пример конкретной ситуации будет? Такие задачи достаточно редки, где нужно именно в многопотоке обрабатывать что-то.

zx_gamer ★★
()
Ответ на: комментарий от zx_gamer

Вот мой код с активно использующимися потоками.

Такие задачи достаточно редки

На самом деле нет. Многопоточность нужна достаточно часто.

liksys ★★★★
()
Ответ на: комментарий от liksys

На самом деле нет. Многопоточность нужна достаточно часто.

Редко. Задачи, где данные не зависят друг от друга и их действительно много встречаются не часто.

zx_gamer ★★
()
Ответ на: комментарий от zx_gamer

Редко

Нет. Не неси ерунду.

Задачи, где данные не зависят друг от друга и их действительно много встречаются не часто.

Как хорошо, что область применения потоков не заканчивается на независимых данных. Иначе ты мог бы оказаться прав :)

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

Вам сколько раз уже объяснили, что программистские проблемы не в языке, а в алгоритмической сложности, и области знаний

Вот мне почему то кажется что это вам ровно это объясняли. Но вы все пищите раст решает все проблемы в дидовской сишке.

заговоры для замены всех индусами

это не заговоры а мировая практика. Причем не индусами - а дешовыми индусами(цыганами пакистанцами хуситами покорителями верхнего ларса - национальность не важна, важна готовность кодить за еду). Так роботает индустрия. Дешовый индус набравшись опыта и знаний отказывается кодить за миску риса, переезжает жить в Лондон (или Купертино или еще куда). Капиталиста волнует только прибыль - а прибыль это доходы минус расходы. Когда ChatGPT*(без понятия как этот скайнет будет называться) научится кодить - все вы ( и мы тоже - что уж тут ) окажемся в очереди у бака с пищевыми отходами как в 30-е годы прошлого века. Но это немного другое. Вам милостивый государь не понять скорее всего - и это ваше счастье. Многие знания умножают скорбь, так что наслаждайтесь юношеским максимализмом пока можете.

Qui-Gon ★★★★★
()
Ответ на: комментарий от Qui-Gon

Когда ChatGPT*…научится кодить

Тогда появиться еще 344 новых профессии, как в случе появления Excel. Который забрал работу у счетоводов которые как раз вручную и занимались переписыванием цифорок в клеточках.

UPD:

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

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 3)
Ответ на: комментарий от Qui-Gon

Вот мне почему то кажется что это вам ровно это объясняли.

Вот именно, что тебе кажется, потому что ты даже не понял, о чем идет речь.

Но вы все пищите раст решает все проблемы в дидовской сишке.

До вас, клоунов, никак не доходит, что раст решает не все, а одну вполне конкретную проблему обращения к памяти. Но вы втемяшили себе какую-то чушь о якобы золотопульном расте, и теперь хоть кол на голове чеши - вообще не слышите, что вам говорят.

Так роботает индустрия.

Об индустрии рассуждает кекс, который даже на своем языке не в состоянии изъясняться без явных орфографических ошибок.

liksys ★★★★
()
Ответ на: комментарий от Qui-Gon

цыганами пакистанцами

Ваши тексты интересно разбирать. Что не строчка то гротескное клише, развестая клюква.

Вот ChatGPT раззоряющий коворкинги, капиталисты в цилидрах запустившие эту махину. А ей противостоит батька Торвальдс и Нарды программисты древности.

Хуситы обжевавшиеся катом (наркотик в виде листьев растения) которые кодят на Rust, подзуживаемые теми же капиталистами в цилиндрах, чтобы отобрать у светлых Си разработчиков их рабочие места.

По моему классно.

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 2)
Ответ на: комментарий от liksys

До вас, клоунов, никак не доходит,

Зря вы так. Это клондайк!

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

Ну где вы еще такое найдете?

lbvf50txt
()
Ответ на: комментарий от lbvf50txt

Ага, орут и тычат в расктрытый K&R пальцами.

liksys ★★★★
()
Ответ на: комментарий от Qui-Gon

важна готовность кодить за еду

Дело в том, что вами описываемые юниты в команде не нужны. Толку от них 0. Корпорации, те самые капиталисты, в команды набирают людей которые достаточно много знают и умеют не только кодировать, но и обьяснять свои решения, а также вести себя (soft skills).

Получается полностью выдуманный мир, где цигане отберают места у квалифицированных разработчиков. Цигане котроые учатся до 5 класса в школе и женятся в 14 лет. Ну это бред, вы уж не сердчайте.

lbvf50txt
()
Ответ на: комментарий от liksys

До вас, клоунов, никак не доходит, что раст решает не все, а одну вполне конкретную проблему обращения к памяти.

Не одну, а все, которые в сишке приводят к неопределённому поведению. Их много: https://github.com/Nekrolm/ubbook

monk ★★★★★
()
Ответ на: комментарий от liksys

Остальные проблемы сишки успешно решает Си++.

А этот набор проблем раньше решали языки со сборщиком мусора (лисп, джава, сишарп, питон, …). Но они медленные и взаимодействие с Си++ не особо простое.

Раст в безопасном варианте работает в среднем быстрее и взаимодействие с небезопасным растом полностью прозрачное. Цена: ограничения на разнообразие алгоритмов в безопасном варианте и борьба с компилятором.

monk ★★★★★
()
Ответ на: комментарий от monk

Остальные проблемы сишки успешно решает Си++.

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

liksys ★★★★
()
Ответ на: комментарий от liksys

И чем, по-твоему, заменить плюсы?

Решаемые проблемы объективны: использование шаблонов вместо макросов, RAII, параметризованные типы и автовывод типов, функторы, …

monk ★★★★★
()
Ответ на: комментарий от liksys

То есть в своей нише (нужна максимально быстрая программа) плюсы являются наилучшим языком из существующих?

monk ★★★★★
()

(пока ждем кусок си, вчера его так и не увидел)

У меня вопрос, поймите меня правильно, это не наезд ради наезда, просто хочу понять, ведь должно быть всему логическое объяснение.

вот читаю:

Стоит отметить, что сами указатели можно определять вне блока unsafe. Однако вне этого блока нельзя обратиться к значению в области памяти, на которую указывает указатель.

и вижу код:

unsafe{
  *num_pointer  = 29;
}

Не много не понял, почему раз есть 1, то это не подразумевает в 2 ? Иными словами когда возмжно обратиться к памяти через указатель без unsafe. Почему unsafe здесь не по умолчанию ?

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 1)
Ответ на: комментарий от mx__

Без unsafe - можно пользоваться умными указателями, с сырыми (raw) - нельзя (читать можно, писать нельзя). Потому что unsafe - это -«Я программист беру ответственность за корректность данного кода». Раст - в большинстве случаев не одобряет скрытые операции. Например: приведение типов только явное, если объект изменяемый -это должно быть указана явно. Исключение - в некоторых случаях, происходит не явное продление жизни объекта. Это описано в главе о времени жизни.

Silerus ★★★★
()
Ответ на: комментарий от Silerus

Стоп. Не очень понял, компилятор не может определить разницу между & и Box что ли ?

Можно кусок кода для примера ?

Я хочу понять в какой момент компилятор может перепутать умную и сырую ссылку (если забыть про адресацию памяти я бы это представил как прямой и относительный указатель)

mx__ ★★★★★
()
Ответ на: комментарий от mx__
 fn main() {
 // это во время компиляции проверяется
    let mut arr = Box::new([' ';100]);
    arr[2]='b';
    println!("{:?}",arr);
    let mut a =[1;100];
    let n =a.as_mut_ptr();
    println!("{:?}",a);
     //*n.add(10)=11;// --так нельзя
    unsafe{
        *n.add(2)=2;// так можно
    }
    println!("{:?}",a);

}

Мы сразу оборачиваем объект в указатель и получаем доступ к внутренним элементам на запись

Silerus ★★★★
()
Ответ на: комментарий от Silerus

Наверное я не понятно пишу, в вашем примере компилятор может и сам догаться что : *n.add(2)=2; это unsafe. Я хочу видеть пример когда компилятор не поймет что перед ним умный указатель или нет.

P.S. Кстати для умной ссылки Вы не показали работу через указатель но и фиг с ним.

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 1)
Ответ на: комментарий от mx__

Без понятия как обмануть компилятор. Вот работа с указателем:

 let mut arr = Box::new([' ';100]);
 let b = arr.as_mut();// b - &mut [char;100]
 b[11]='f';
 println!("{:?}",arr);
Silerus ★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.