- Представлена библиотека Aya для создания eBPF-обработчиков н..., lockywolf, 10:39 , 16-Июн-21 (1) +1
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Ordu, 11:24 , 16-Июн-21 (7) +1
Как обычно, надо полагать. Data race исключаются как класс, пока ты не прибегаешь к unsafe, а остальное всё в твоих руках. А почему ты спрашиваешь? Есть основания полагать, что у него ситуация с thread-safety отличается от дефолтной в расте?
- Представлена библиотека Aya для создания eBPF-обработчиков н..., lockywolf, 12:14 , 16-Июн-21 (14) +1
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Ordu, 12:38 , 16-Июн-21 (15)
> Ну, я помню смешные курьёзы с errno, который в стандарте переменная, но > для thread-safety сделано как макрос, разворачивающийся в вызов функции.Чё за курьёзы? Я не помню. Мне было бы интересно посмотреть, как кто-то не справился не заметить таких нюансов. > Интересно, помнили > ли об этом растовики, когда писали свой crate. А, ну это общая проблема создания safe API поверх unsafe операций. Тут она несколько осложняется тем, что там unsafe будет во все поля из-за интерфейса с внешним кодом, который rustc не может проанализировать на safety, и поэтому на всякий случай считает unsafe. То есть, в unsafe будет заворачиваться слишком много, и поэтому придётся проявлять чудеса умения обходить грабли. Да, вероятность косяков повышена. Тут ты прав.
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Аноним, 13:29 , 16-Июн-21 (19)
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Прорыв_запарты_фелиал, 20:59 , 16-Июн-21 (38) –4 [V]
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Ordu, 21:20 , 16-Июн-21 (41) +6 [^]
> А вот и жертвы пропаганды нарисовались. Модель памяти раста не предполагает конкурентного > доступа, а когда нет конкурентного доступа нет гонок.race condition в расте делается элементарно. Сделай два mutex'а, и попробуй залочить их оба последовательно из параллельных потоков. data race в расте элементарно не делается, unsafe нужен, как раз в силу этой самой модели памяти. А конкурентный доступ есть, чтобы какую бы лапшу _тебе_ пропаганда не вешала на уши, есть Arc для менеджмента памятью в конкурентном окружении, и есть Mutex, для конкрентного доступа. Есть Send, говорящий о том, что значения данного типа можно прокидывать между потоками выполнения. Наконец, есть Sync, для типов навроде Mutex'а, которые не просто можно прокидывать между потоками, но шарить между потоками, в смысле иметь указатели на них в разных потоках одновременно. И если Arc и Mutex -- это творения стандартной библиотеки и дают простор порассуждать, что это не раст как таковой, а библиотека к нему, то Send и Sync -- это трейты-маркеры типов, прошитые в язык, наряду с другими трейтами-маркерами формирующими модель памяти раста (чтобы это не означало), такими как Clone, Copy, ?Sized. > Тебя обманули. Конечно. > Представляешь, отличается. Раз раст не может в конкурентный доступ, то любое его > наличие требует unsafe, Да, ты прикинь, они врут всё про безопасность: массивы тоже в расте не реализуются без unsafe'ов. Ты реально можешь заглянуть в сорцы core::slice и увидеть там как unsafe на unsafe unsafe'ом погоняет: https://doc.rust-lang.org/src/core/slice/mod.rs.html#86
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Прорыв_запарты_фелиал, 21:36 , 16-Июн-21 (46) +1
- Представлена библиотека Aya для создания eBPF-обработчиков н..., zig, 22:23 , 16-Июн-21 (60) +1
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Ordu, 22:33 , 16-Июн-21 (63) +5
>>race condition в расте делается элементарно. Сделай два mutex'а, и попробуй залочить их оба последовательно из параллельных потоков. > Раст не умеет в mutex - он не реализуется на расте. Это > раз. Два - мутекс это не конкурентный доступ. Это костыль, который > делает из конкурентного неконкурентный.Да-да, точно, и массивов в расте нет, потому что они реализуются на расте. > К тому же, даже если обернуть ворованный сишный мутекс в фейковое safe, > то это не будет работать. Конкурентного доступа всё равно не будет. > Т.е. обращаться ты сможешь только через глобальный мутекс. Что значит "глобальный мьютекс"? Мьютекс в расте -- это часть типа. Если я пишу Mutex<Vec<f32>>, то это тип, который можно прочитать, например, так: прикрытый мьютексом динамический массив 32-битных флоатов. Где здесь "глобальность мьютекса"? > Это уже не гарантия раста, а гарантия рантайма. Эмм, да. А в чём разница? Сколь-нибудь практически полезный конкурентный доступ невозможен без гарантий рантайма. > И повторю - ссылку можно получить > только при захвате мутекса, а значит никакого конкурентного доступа нет. Если ты так говоришь... нуок. И чё, теперь? Нахрен кому нужен твой конкурентный доступ, если он приводит к датарейсам? > Доступ есть только к мутексу, который вопрованный сишный. В сях мьютексы уворованны из ассемблера. То есть, некоторые компиляторы могут иметь вендор-специфичные builtin'ы, навроде cmpxchg или там atomic_increment, или что-нибудь типа. Но это не стандарт C, это вендорспецифичная штука. А вообще это делается inline-асмом. C просто не имеет атомарных операций, необходимых для реализации примитивов синхронизации, типа cmpxchg. В расте они, кстати, предоставляются builtin'ами, и часть стандартной библиотеки. https://doc.rust-lang.org/std/sync/atomic/index.html >>data race в расте элементарно не делается, unsafe нужен, как раз в силу этой самой модели памяти. > Ещё раз - тебя поимела пропаганда. Никакие data race в расте не > делаются. Ну, я как бы и том и говорю, что не делаются. Я не понимаю с чем или с кем ты споришь сейчас. Я о том же говорю, что data race не делаются. Я говорю, что race-condition делаются легко. > Гонка предполагает шаринг, а наличие шаринга в расте - это > уб. Нет, не-Sync шаринг -- это UB. Sync значения вполне можно шарить, и Mutex тому библиотечный пример. > Давай ещё раз. Раст не даёт возможность шарить данные, а если не > шарить данные гонок нет. Поэтому попытка написать шаринг на расте продуцирует > невозможность. Ты можешь повторять это по десять раз каждый день на сон грядущий. От этого шаринг из раста никуда не денется. >>И если Arc и Mutex -- это творения стандартной библиотеки и дают простор порассуждать, что это не раст как таковой, а библиотека к нему, то Send и Sync -- это трейты-маркеры типов, прошитые в язык, наряду с другими трейтами-маркерами формирующими модель памяти раста (чтобы это не означало), такими как Clone, Copy, ?Sized. > Нет, никакая эта херня не имеет никакого отношения к языку. Всё это > ансейф-хаки не выражаемые на расте. То, что она валяются в stdlib > - причина одна. Любая скриптуха не способна выразить свою stdlib, поэтому > эта stdlib всегда пишется на отдельном языке. Враньё. std лиспа написан на лиспе. std C написан на C. std раста написан на расте. Ну, C и раст наверное нельзя включить в категорию "скриптуха", но лисп прям таким просится туда. >>Да, ты прикинь, они врут всё про безопасность: массивы тоже в расте не реализуются без unsafe'ов. Ты реально можешь заглянуть в сорцы core::slice и увидеть там как unsafe на unsafe unsafe'ом погоняет: https://doc.rust-lang.org/src/core/slice/mod.rs.html#86 > Зачем мне куда-то заглядывать, если я, в отличии от жертвы пропаганды, понимаю > модель памяти используемую растом. А я не понимаю. Я даже не понимаю, что ты имеешь в виду под "моделью памяти". Что за модель памяти? Что-то типа RAM, EM, VAT[1]? Нет, наверное, это всё ж теоретические модели памяти _машины_, а не языка. Или что-то типа этого[2]? Не мог бы ты поделиться ссылкой, на тот теоретический фреймворк, в который позволяет тебе выстроить модель памяти раста? [1] https://core.ac.uk/download/pdf/18462805.pdf [2] http://canonical.org/~kragen/memory-models/ Но в любом случае, я скажу тебе одну простую вещь: любая "модель" -- это лишь модель. То есть теория, которая игнорирует существенную часть реальность, для того, чтобы когнитивные дефициты теоретика не мешали бы ему думатьо проблеме. В реальности же, программы на rust не просто имеют конкурентный доступ, они налево и направо им пользуются. Да, они избегают его, потому что раст начинает хмурится. Да, когда они его используют, они стараются обходится const доступом, но это не значит, что нельзя иметь глобальную хеш-табличку символов, где можно конкурентно эти символы искать и откуда их можно конкуретно тягать. > И, очевидно, могу вывести из неё возможное > и невозможное. Нет, из модели ты _по-определению_ модели не можешь вывести всего. Модель по-определению и по-построению рассматривает только некоторые свойства реальности, игнорируя все остальные. Из геометрии Евклида ты не выведешь общую теорию относительности с её пространством-временем. Хотя геометрия Евклида -- это модель пространства, в котором мы живём. Так и из модели памяти языка ты не сможешь вывести все возможные утверждения про язык. Более того, не все утверждения про язык, которые ты сможешь вывести будут применимы.
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Аноним, 15:30 , 18-Июн-21 (134)
- Представлена библиотека Aya для создания eBPF-обработчиков н..., mos87, 10:47 , 16-Июн-21 (2) –1
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Qwerty, 10:52 , 16-Июн-21 (3) –12 [V]
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Аноним, 11:09 , 16-Июн-21 (5) –1
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Аноним, 11:21 , 16-Июн-21 (6) +13 [V]
- Представлена библиотека Aya для создания eBPF-обработчиков н..., псевдонимус, 11:24 , 16-Июн-21 (8) +5
- Представлена библиотека Aya для создания eBPF-обработчиков н..., anonymous, 17:39 , 16-Июн-21 (27) +2
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Аноним, 17:54 , 16-Июн-21 (28) +2
- Заменили одну обёртку на другую, Алексей, 18:12 , 16-Июн-21 (29) +1
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Аноним, 21:28 , 16-Июн-21 (44) +7 [^]
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Аноним, 22:20 , 16-Июн-21 (59)
- Представлена библиотека Aya для создания eBPF-обработчиков н..., растоманам надо, 22:31 , 16-Июн-21 (62) +2
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Annoynymous, 08:57 , 17-Июн-21 (72) +1
- Представлена библиотека Aya для создания eBPF-обработчиков н..., YetAnotherOnanym, 12:03 , 17-Июн-21 (77) +2
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Fractal cucumber, 12:10 , 17-Июн-21 (78) +1
- Представлена библиотека Aya для создания eBPF-обработчиков н..., балмер в маске V, 20:15 , 17-Июн-21 (105) +1
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Аноним, 01:35 , 18-Июн-21 (119)
- Представлена библиотека Aya для создания eBPF-обработчиков н..., Аноним, 01:42 , 18-Июн-21 (121)
|