Unit Instance

HTTP 200 OK
Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_linux-emulation/en/?format=api",
    "source": [
        "Threads in computer science are entities within a process that can be scheduled independently from each other. The threads in the process share process wide data (file descriptors, etc.) but also have their own stack for their own data. Sometimes there is a need for process-wide data specific to a given thread. Imagine a name of the thread in execution or something like that. The traditional <trademark class=\"registered\">UNIX</trademark> threading API, <application>pthreads</application> provides a way to do it via <citerefentry><refentrytitle>pthread_key_create</refentrytitle><manvolnum>3</manvolnum></citerefentry>, <citerefentry><refentrytitle>pthread_setspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> and <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> where a thread can create a key to the thread local data and using <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> or <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> to manipulate those data. You can easily see that this is not the most comfortable way this could be accomplished. So various producers of C/C++ compilers introduced a better way. They defined a new modifier keyword thread that specifies that a variable is thread specific. A new method of accessing such variables was developed as well (at least on i386). The <application>pthreads</application> method tends to be implemented in userspace as a trivial lookup table. The performance of such a solution is not very good. So the new method uses (on i386) segment registers to address a segment, where TLS area is stored so the actual accessing of a thread variable is just appending the segment register to the address thus addressing via it. The segment registers are usually <varname>%gs</varname> and <varname>%fs</varname> acting like segment selectors. Every thread has its own area where the thread local data are stored and the segment must be loaded on every context switch. This method is very fast and used almost exclusively in the whole i386 <trademark class=\"registered\">UNIX</trademark> world. Both FreeBSD and <trademark class=\"registered\">Linux</trademark> implement this approach and it yields very good results. The only drawback is the need to reload the segment on every context switch which can slowdown context switches. FreeBSD tries to avoid this overhead by using only 1 segment descriptor for this while <trademark class=\"registered\">Linux</trademark> uses 3. Interesting thing is that almost nothing uses more than 1 descriptor (only <application>Wine</application> seems to use 2) so <trademark class=\"registered\">Linux</trademark> pays this unnecessary price for context switches."
    ],
    "previous_source": "",
    "target": [
        "Threads in computer science are entities within a process that can be scheduled independently from each other. The threads in the process share process wide data (file descriptors, etc.) but also have their own stack for their own data. Sometimes there is a need for process-wide data specific to a given thread. Imagine a name of the thread in execution or something like that. The traditional <trademark class=\"registered\">UNIX</trademark> threading API, <application>pthreads</application> provides a way to do it via <citerefentry><refentrytitle>pthread_key_create</refentrytitle><manvolnum>3</manvolnum></citerefentry>, <citerefentry><refentrytitle>pthread_setspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> and <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> where a thread can create a key to the thread local data and using <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> or <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> to manipulate those data. You can easily see that this is not the most comfortable way this could be accomplished. So various producers of C/C++ compilers introduced a better way. They defined a new modifier keyword thread that specifies that a variable is thread specific. A new method of accessing such variables was developed as well (at least on i386). The <application>pthreads</application> method tends to be implemented in userspace as a trivial lookup table. The performance of such a solution is not very good. So the new method uses (on i386) segment registers to address a segment, where TLS area is stored so the actual accessing of a thread variable is just appending the segment register to the address thus addressing via it. The segment registers are usually <varname>%gs</varname> and <varname>%fs</varname> acting like segment selectors. Every thread has its own area where the thread local data are stored and the segment must be loaded on every context switch. This method is very fast and used almost exclusively in the whole i386 <trademark class=\"registered\">UNIX</trademark> world. Both FreeBSD and <trademark class=\"registered\">Linux</trademark> implement this approach and it yields very good results. The only drawback is the need to reload the segment on every context switch which can slowdown context switches. FreeBSD tries to avoid this overhead by using only 1 segment descriptor for this while <trademark class=\"registered\">Linux</trademark> uses 3. Interesting thing is that almost nothing uses more than 1 descriptor (only <application>Wine</application> seems to use 2) so <trademark class=\"registered\">Linux</trademark> pays this unnecessary price for context switches."
    ],
    "id_hash": 960278411420594378,
    "content_hash": 960278411420594378,
    "location": "article.translate.xml:1820",
    "context": "",
    "note": "(itstool) path: sect3/para",
    "flags": "",
    "labels": [],
    "state": 100,
    "fuzzy": false,
    "translated": true,
    "approved": false,
    "position": 274,
    "has_suggestion": false,
    "has_comment": false,
    "has_failing_check": false,
    "num_words": 352,
    "source_unit": "https://translate-dev.freebsd.org/api/units/99671/?format=api",
    "priority": 100,
    "id": 99671,
    "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_linux-emulation/en/?checksum=8d5398209e3370ca",
    "url": "https://translate-dev.freebsd.org/api/units/99671/?format=api",
    "explanation": "",
    "extra_flags": "",
    "pending": false,
    "timestamp": "2019-10-20T12:10:41.119672Z"
}