[О блоге] [наверх] [пред] [2022-11-14 10:05:23+03:00] [5eb8e4bc830f663fe8644439b6889b9447adfa64]
Темы: [bsd][plan9]

rfork как замена thread-ам

https://www.unix.com/man-page/freebsd/2/rfork/
https://en.wikipedia.org/wiki/Fork_(system_call)#Rfork
https://plan9.io/magic/man2html/2/fork
В B системахSD есть rfork() вызов, изобретённый ещё в Plan 9. Один вызов
для создания или отдельного fork()-like процесса или для thread-ов.

    [оставить комментарий]
    комментарий 0:
    From: kmeaw
    Date: 2022-11-14 10:05:18Z
    
    В Linux тоже есть clone(2), но я не уверен, что про этот вызов можно
    сказать, что он создаёт thread - это только кусочек работы (хотя и самый
    важный).
    
    Стандартная библиотека C предоставляет интерфейс (FILE*) для работы с
    файлами, аллокатор памяти, примитивы синхронизации. Последние особенно
    важны в многопоточных приложениях. Многие стандартные библиотеки также
    помогают с раскруткой стека (для кооперации с отладчиком и печати stack
    trace), реализуют загрузчик динамических разделяемых библиотек, защищают
    от переполнения стека с помощью guard page.
    
    Эти механизмы завязаны на инициализацию памяти thread определённым
    образом, особенно thread local storage, в начале которого лежит thread
    control block. Неправильное заполнение этого блока (например из-за
    непосредственного использования clone вместо pthread_create) может
    привести к тому, что всё вроде бы работает, но программа зависает на
    чём-то вроде бы безобидном, типа assert() или взятии лока на точно
    свободном mutex. getpid()/thread_self() могут вернуть совсем не то, чего
    ожидаешь.
    
    комментарий 1:
    From: Sergey Matveev
    Date: 2022-11-16 09:13:55Z
    
    *** kmeaw [2022-11-14 13:03]:
    >В Linux тоже есть clone(2), но я не уверен, что про этот вызов можно
    >сказать, что он создаёт thread - это только кусочек работы (хотя и самый
    >важный).
    
    Ага, в man rfork FreeBSD тоже говорится про то, что memory sharing
    приведёт запросто к не очень рабочему решению:
    
    RFMEM            If set, the kernel will force sharing of the entire
                     address space, typically by sharing the hardware page
                     table directly.  The child will thus inherit and share
                     all the segments the parent process owns, whether they
                     are normally shareable or not.  The stack segment is not
                     split (both the parent and child return on the same
                     stack) and thus rfork() with the RFMEM flag may not
                     generally be called directly from high level languages
                     including C.  May be set only with RFPROC.  A helper
                     function is provided to assist with this problem and
                     will cause the new process to run on the provided stack.
                     See rfork_thread(3) for information.  Note that a lot of
                     code will not run correctly in such an environment.
    
    При этом rfork_thread "has been deprecated in favor of pthread_create".
    Так что на практике конечно же не стоит это ни в BSD, ни в Linux
    использовать для имитации тредов.