Units API.

See the Weblate's Web API documentation for detailed description of the API.

GET /api/units/26539/?format=api
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/es/?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": [
        "Los subprocesos en ciencias de la computación son entidades dentro de un proceso que se pueden programar de forma independiente entre sí. Los subprocesos del proceso comparten datos de todo el proceso (descriptores de archivo, etc.) pero también tienen su propia pila para sus propios datos. A veces existe la necesidad de datos de todo el proceso específicos para un hilo dado. Imagina un nombre del hilo en ejecución o algo así. Lo tradicional <trademark class=\"registered\">UNIX</trademark> API de subprocesos, <application>pthreads</application> proporciona una forma de hacerlo a través de <citerefentry><refentrytitle>pthread_key_create</refentrytitle><manvolnum>3</manvolnum></citerefentry>, <citerefentry><refentrytitle>pthread_setspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> y <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> donde un hilo puede crear una clave para los datos locales del hilo y usar <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> o <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> para manipular esos datos. Puede ver fácilmente que esta no es la forma más cómoda de lograrlo. Entonces, varios productores de compiladores C / C ++ introdujeron una mejor manera. Definieron un nuevo hilo de palabra clave modificadora que especifica que una variable es específica del hilo. También se desarrolló un nuevo método para acceder a tales variables (al menos en i386). los <application>pthreads</application> El método tiende a implementarse en el espacio de usuario como una tabla de búsqueda trivial. El rendimiento de esta solución no es muy bueno. Por lo tanto, el nuevo método usa (en i386) registros de segmento para direccionar un segmento, donde el área TLS se almacena, por lo que el acceso real de una variable de subproceso es simplemente agregar el registro de segmento a la dirección, por lo que se direcciona a través de ella. Los registros de segmento suelen ser <varname>%gs</varname> and <varname>%fs</varname> actuando como selectores de segmento. Cada hilo tiene su propia área donde se almacenan los datos locales del hilo y el segmento se debe cargar en cada cambio de contexto. Este método es muy rápido y se utiliza casi exclusivamente en todo el i386. <trademark class=\"registered\">UNIX</trademark> mundo. Tanto FreeBSD como <trademark class=\"registered\">Linux</trademark> implementar este enfoque y produce muy buenos resultados. El único inconveniente es la necesidad de volver a cargar el segmento en cada cambio de contexto que puede ralentizar los cambios de contexto. FreeBSD intenta evitar esta sobrecarga usando solo 1 descriptor de segmento para esto mientras <trademark class=\"registered\">Linux</trademark> utiliza 3. Lo interesante es que casi nada utiliza más de 1 descriptor (solo <application>Wine</application> parece usar 2) entonces<trademark class=\"registered\">Linux</trademark> paga este precio innecesario por los cambios de contexto."
    ],
    "id_hash": 960278411420594378,
    "content_hash": 960278411420594378,
    "location": "article.translate.xml:1820",
    "context": "",
    "note": "(itstool) path: sect3/para",
    "flags": "",
    "labels": [],
    "state": 20,
    "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": 26539,
    "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_linux-emulation/es/?checksum=8d5398209e3370ca",
    "url": "https://translate-dev.freebsd.org/api/units/26539/?format=api",
    "explanation": "",
    "extra_flags": "",
    "pending": false,
    "timestamp": "2019-10-20T12:10:41.119672Z"
}