Changes API.

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

GET /api/changes/52109/?format=api
HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "unit": "https://translate-dev.freebsd.org/api/units/26937/?format=api",
    "component": "https://translate-dev.freebsd.org/api/components/freebsd-doc/articles_linux-emulation/?format=api",
    "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_linux-emulation/pt_BR/?format=api",
    "user": "https://translate-dev.freebsd.org/api/users/ebrandi/?format=api",
    "author": "https://translate-dev.freebsd.org/api/users/ebrandi/?format=api",
    "timestamp": "2019-11-09T00:56:21.856402Z",
    "action": 2,
    "target": "Threads precisam de algum tipo de sincronização e <trademark class=\"registered\">POSIX</trademark> fornece alguns deles: mutexes para exclusão mútua, bloqueios de leitura/gravação para exclusão mútua com relação de polarização de leituras e gravações e variáveis de condição para sinalizar um mudança de status. É interessante observar que a API de thread <trademark class=\"registered\">POSIX</trademark> não tem suporte para semáforos. Essas implementações de rotinas de sincronização são altamente dependentes do tipo de suporte a threading que temos. No modelo puro 1:M (espaço de usuário), a implementação pode ser feita apenas no espaço do usuário e, portanto, ser muito rápida (as variáveis de condição provavelmente serão implementadas usando sinais, ou seja, não rápido) e simples. No modelo 1:1, a situação também é bastante clara - as threading devem ser sincronizadas usando as facilidades do kernel (o que é muito lento porque uma syscall deve ser executada). O cenário M:N misto combina apenas a primeira e a segunda abordagem ou depende apenas do kernel. A sincronização de threads é uma parte vital da programação ativada por threads e seu desempenho pode afetar muito o programa resultante. Benchmarks recentes no sistema operacional FreeBSD mostraram que uma implementação sx_lock melhorada gerou 40% de aceleração no <firstterm>ZFS</firstterm> (um usuário sx pesado), isso é algo in-kernel, mas mostra claramente quão importante é o desempenho das primitivas de sincronização. .",
    "id": 52109,
    "action_name": "Vertaling aangepast",
    "url": "https://translate-dev.freebsd.org/api/changes/52109/?format=api"
}