к такому жизнь меня не готовила

ребят, а разве в расте не действует принцип - если скоплилилось то значит все норм?

Если это borrowed ошибка, разве она не в компайл тайме отслеживается?

можно компилить ансэйф

это считается за "все норм"?

может оно валится из-за внешних факторов, ну там файл открыть/записать не смог или типа того

или ты выиграл приз в игре - урони rust, кажется у них был такой конкурс

ребят, а разве в расте не действует принцип - если скоплилилось то значит все норм?

а ты не юзал какой нибудь типаж который выносит эту проверку в рантайм?

а ты не юзал какой нибудь типаж который выносит эту проверку в рантайм?

в душе не ебу, сделал вызов запроса на элемент в билдере

и все чот уронилось

может оно валится из-за внешних факторов, ну там файл открыть/записать не смог или типа того

да не, там с файловой системой ничего не связано

можно компилить ансэйф

нету у меня ансейфов

сегодня делал интеграцию этого вашего fluent-rust

мальца заебался, но там мои ляпы были

щас вроде все топчик

осталось только узнать нахуя я его использовал?

(ладно просто потому что я ненавижу gettext файлы)

или ты выиграл приз в игре - урони rust, кажется у них был такой конкурс

да видимо я очередной "победитель"

да видимо я очередной "победитель"

Запили им issue, вдруг это действительно баг япа.

рантаймовый борроу специально сделан для некоторых типов, нет?

или я чего то путаю?

возможно это глюк ffi бинда для gtk

вполне возможно

там гдето в кишках оболочки чтото замкнуло и ебнуло

так то не паника а сегфолт должен быть

словил borrowed паник в рантайме

Так RefCell же

Так RefCell же

+1

Rust не делает какую-то магию. Раст даёт программеру выбор какой инструмент использовать.

Проверять всё статически не всегда возможно. Поэтому есть возможность что-то предпринимать в подобных ситуациях по ходу дела.

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

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

слишком много неконтролируемого GUI говна поверх FFI чтобы это еще и тестировать

лучше сразу выпилится нахуй чем пытаться это сейчас тестить чтобы те 3 строчки что вызывали фаталку заработали

"Разделяй и властвуй" ©

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

https://pypl.github.io/PYPL.html

а ты не юзал какой нибудь типаж который выносит эту проверку в рантайм?

^ других вариантов не может быть

RefCell<T> uses Rust's lifetimes to implement 'dynamic borrowing', a process whereby one can claim temporary, exclusive, mutable access to the inner value. Borrows for RefCell<T>s are tracked 'at runtime', unlike Rust's native reference types which are entirely tracked statically, at compile time. Because RefCell<T> borrows are dynamic it is possible to attempt to borrow a value that is already mutably borrowed; when this happens it results in thread panic.

чем паника отличается от сегфолта?

сегфолт — это же сигнал. AFAIK, Он ловиться, кидается управление в ядро и возможно передается управление в обработчик из приложения паники они попроще. Насколько я понимаю они реализованы на манер С++ исключений.

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

попробуй сделать панику в другом треде и попробуй сделать сегфолт в другом треде

во! кстати да

паники в Rust'е убивают тред

Еще их перехватить можно, как исключение в C++

Ну и паника разматывает стэк, дропая все объекты

такс, у меня вопрос, в расте работают setuid/setgid?

хм, а почему бы им не работать?

Работают

хм, а почему бы им не работать?

Ну в го работают не так, как ожидаешь, например

Ну в го работают не так, как ожидаешь, например

Это интересно, а что с ним не так?

Это интересно, а что с ним не так?

На один тред несколько горутин

имеет смысл

На один тред несколько горутин

А uid вешается на поток?

https://github.com/golang/go/issues/1435 забавные результаты по запросу setuid threads

В linux да, но libc делает синхронизацию

В linux да, но libc делает синхронизацию

хм, да чтож такое

я имею ввиду казалось то все просто

какую синхронизацию делает libc?

Ну в го работают не так, как ожидаешь, например

в го из-за этого вырубили совсем

с 1.4

Линуксе же через жопу сделано. Поток - это процесс на самом деле...

так ну все разрыв шаблонов

Линуксе же через жопу сделано. Поток - это процесс на самом деле...

поясните пожалуйста

в линухе тред тяжелый

и от форка отличается лишь шаред памятью

В линухе можно шарить адресное пространство, файловые дескрипторы и все прочее между процессами (системный вызов clone). Поток - это такой процесс с которым все расшарено

Линуксе же через жопу сделано. Поток - это процесс на самом деле...

А ты хочешь, чтобы операционная система имела раздельные шедулеры для потоков и процессов? Единство потоков и процессов очень крутая идея, потому что можно разграничивать степень "общности" разных процессов

ого! а набор дескрипторов напимер?

А ты хочешь, чтобы операционная система имела раздельные шедулеры для потоков и процессов? Единство потоков и процессов очень крутая идея, потому что можно разграничивать степень "общности" разных процессов

с другой стороны потоки не такие легковесные

когда происходит форк- чил процес наследуется от парента и память становится CoW

при треде - память общая - но тред по сути отдельный проццес

сумбурно

с другой стороны потоки не такие легковесные

ТУПО ЗДЕЛОЛИ, пойду эрланг изучать

эликсир

ого! а набор дескрипторов напимер?

https://linux.die.net/man/2/clone CLONE_FILES (since Linux 2.0)If CLONE_FILES is set, the calling process and the child process share the same file descriptor table. Any file descriptor created by the calling process or by the child process is also valid in the other process. Similarly, if one of the processes closes a file descriptor, or changes its associated flags (using the fcntl(2) F_SETFD operation), the other process is also affected. If CLONE_FILES is not set, the child process inherits a copy of all file descriptors opened in the calling process at the time of clone(). (The duplicated file descriptors in the child refer to the same open file descriptions (see open(2)) as the corresponding file descriptors in the calling process.) Subsequent operations that open or close file descriptors, or change file descriptor flags, performed by either the calling process or the child process do not affect the other process.

Ну собственно по этому все люди носятся с идее green threads / fibers и т.д.

так! а чисто получается phtreads можно поверх libc/сырых syscall'ах сделать? Или есть специальные syscall'ы спецом для pthreads?

так! а чисто получается phtreads можно поверх libc/сырых syscall'ах сделать? Или есть специальные syscall'ы спецом для pthreads?

Этот сисколл (clone) только линуксовый же вроде. Нестандартный. По верх него стандартный pthreads работает

окей, я уточню: "реализация pthreads для linux'а"

эликсир

после него