Translation

(itstool) path: sect2/para
Mutexes in FreeBSD kernel (see <citerefentry><refentrytitle>mutex</refentrytitle><manvolnum>9</manvolnum></citerefentry>) have one distinction from their more common userland cousins — the code cannot sleep while holding a mutex). If the code needs to sleep a lot, <citerefentry><refentrytitle>sx</refentrytitle><manvolnum>9</manvolnum></citerefentry> locks may be more appropriate. On the other hand, if you do almost everything in a single thread, you may get away with no mutexes at all.
510/4900
Context English Portuguese (Brazil) State
Now, the notification of bio completion <quote>bubbles up</quote> in the <literal>g_up</literal> thread. First the partition slicer gets <function>.done</function>() called in the <literal>g_up</literal> thread, it uses information stored in the bio to free the cloned <varname remap="structname">bio</varname> structure (with <function>g_destroy_bio</function>()) and calls <function>g_io_deliver</function>() on the original request. Agora, a notificação de bio conclusão <quote>borbulha</quote> na thread <literal>g_up</literal>. Primeiro, o slicer de partição obtém <function>.done</function>() chamado na thread <literal>g_up</literal>, ele usa as informações armazenadas na bio para liberar a estrutura <varname remap="structname">bio</varname> clonada (com <function>g_destroy_bio</function>()) e chama <function>g_io_deliver</function>() no pedido original.
The filesystem gets the data and transfers it to userland. O sistema de arquivos obtém os dados e os transfere para o usuário.
See <citerefentry><refentrytitle>g_bio</refentrytitle><manvolnum>9</manvolnum></citerefentry> man page for information how the data is passed back and forth in the <varname remap="structname">bio</varname> structure (note in particular the <varname>bio_parent</varname> and <varname>bio_children</varname> fields and how they are handled). Veja a página de manual para o <citerefentry><refentrytitle>g_bio</refentrytitle><manvolnum>9</manvolnum></citerefentry> para obter informações sobre como os dados são passados para frente e para trás na estrutura <varname remap="structname">bio</varname> (observe em particular os campos <varname>bio_parent</varname> e <varname>bio_children</varname> e como eles são manipulados).
One important feature is: <emphasis>THERE CAN BE NO SLEEPING IN G_UP AND G_DOWN THREADS</emphasis>. This means that none of the following things can be done in those threads (the list is of course not complete, but only informative): Uma característica importante: <emphasis>NAS THREADS G_UP E G_DOWN NÃO SE PODE DORMIR (SELEEPING)</emphasis>. Isso significa que nenhuma das seguintes coisas pode ser feita nessas threads (a lista não é completa, mas apenas informativa):
Calls to <function>msleep</function>() and <function>tsleep</function>(), obviously. Chamadas para <function>msleep</function>() e <function>tsleep</function>(), obviamente.
Calls to <function>g_write_data</function>() and <function>g_read_data</function>(), because these sleep between passing the data to consumers and returning. Chamadas para <function>g_write_data</function>() e <function>g_read_data</function>(), porque estes dormem entre passar os dados para os consumidores e retornar.
Waiting for I/O. Esperando I/O.
Calls to <citerefentry><refentrytitle>malloc</refentrytitle><manvolnum>9</manvolnum></citerefentry> and <function>uma_zalloc</function>() with <varname>M_WAITOK</varname> flag set Chamadas para <citerefentry><refentrytitle>malloc</refentrytitle><manvolnum>9</manvolnum></citerefentry> e <function>uma_zalloc</function>() com o conjunto de flags <varname>M_WAITOK</varname>
sx and other sleepable locks sx e outros sleepable locks
This restriction is here to stop GEOM code clogging the I/O request path, since sleeping is usually not time-bound and there can be no guarantees on how long will it take (there are some other, more technical reasons also). It also means that there is not much that can be done in those threads; for example, almost any complex thing requires memory allocation. Fortunately, there is a way out: creating additional kernel threads. Esta restrição está aqui para impedir que o código GEOM obstrua o caminho da solicitação de I/O, já que sleeping normalmente não é limitado pelo tempo e não pode haver garantias sobre quanto tempo levará (também existem algumas outras razões mais técnicas). Isso também significa que não existe muito o que possa ser feito nessas threads; por exemplo, quase qualquer coisa complexa requer alocação de memória. Felizmente, existe uma saída: criar threads adicionais no kernel.
Kernel Threads for Use in GEOM Code Threads de kernel para uso no código GEOM
Kernel threads are created with <citerefentry><refentrytitle>kthread_create</refentrytitle><manvolnum>9</manvolnum></citerefentry> function, and they are sort of similar to userland threads in behavior, only they cannot return to caller to signify termination, but must call <citerefentry><refentrytitle>kthread_exit</refentrytitle><manvolnum>9</manvolnum></citerefentry>. As threads do kernel são criadas com a função <citerefentry><refentrytitle>kthread_create</refentrytitle><manvolnum>9</manvolnum></citerefentry>, e elas são semelhantes aos threads do userland no comportamento, eles somente não podem retornar ao chamador para exprimir a conclusão, mas deve chamar <citerefentry><refentrytitle>kthread_exit</refentrytitle><manvolnum>9</manvolnum></citerefentry>.
In GEOM code, the usual use of threads is to offload processing of requests from <literal>g_down</literal> thread (the <function>.start</function>() function). These threads look like <quote>event handlers</quote>: they have a linked list of event associated with them (on which events can be posted by various functions in various threads so it must be protected by a mutex), take the events from the list one by one and process them in a big <literal>switch</literal>() statement. No código GEOM, o uso usual de threads é para descarregar o processamento de requisições da thread <literal>g_down</literal> (a função <function>.start</function>). Estas threads se parecem com um <quote>event handlers</quote>: elas têm uma lista encadeada de eventos associados a elas (nos quais eventos podem ser postados por várias funções em várias threads, portanto, devem ser protegidos por um mutex), pegam os eventos da lista, um por um, e processa-os em uma grande instrução <literal>switch</literal>().
The main benefit of using a thread to handle I/O requests is that it can sleep when needed. Now, this sounds good, but should be carefully thought out. Sleeping is well and very convenient but can very effectively destroy performance of the geom transformation. Extremely performance-sensitive classes probably should do all the work in <function>.start</function>() function call, taking great care to handle out-of-memory and similar errors. A principal vantagem de usar uma thread para lidar com solicitações de I/O é que ela pode dormir quando necessário. Agora, isso parece bom, mas deve ser cuidadosamente pensado. Dormir é bom e muito conveniente, mas pode ser muito efetivo em destruir o desempenho da transformação geom. As classes extremamente sensíveis ao desempenho provavelmente devem fazer todo o trabalho na chamada de função <function>.start</function>(), tomando muito cuidado para lidar com erros de falta de memória e similares.
The other benefit of having a event-handler thread like that is to serialize all the requests and responses coming from different geom threads into one thread. This is also very convenient but can be slow. In most cases, handling of <function>.done</function>() requests can be left to the <literal>g_up</literal> thread. O outro benefício de ter uma thread de manipulação de eventos como essa é serializar todas as solicitações e respostas provenientes de diferentes threads geom em uma thread. Isso também é muito conveniente, mas pode ser lento. Na maioria dos casos, o tratamento de pedidos <function>.done</function>() pode ser deixado para a thread <literal>g_up</literal>.
Mutexes in FreeBSD kernel (see <citerefentry><refentrytitle>mutex</refentrytitle><manvolnum>9</manvolnum></citerefentry>) have one distinction from their more common userland cousins — the code cannot sleep while holding a mutex). If the code needs to sleep a lot, <citerefentry><refentrytitle>sx</refentrytitle><manvolnum>9</manvolnum></citerefentry> locks may be more appropriate. On the other hand, if you do almost everything in a single thread, you may get away with no mutexes at all. Mutexes no kernel do FreeBSD (veja <citerefentry><refentrytitle>mutex</refentrytitle><manvolnum>9</manvolnum></citerefentry>) têm uma distinção de seus primos mais comuns do userland - o código não pode dormir enquanto estiver segurando um mutex). Se o código precisar dormir muito, os bloqueios <citerefentry><refentrytitle>sx</refentrytitle><manvolnum>9</manvolnum></citerefentry> podem ser mais apropriados. Por outro lado, se você faz quase tudo em um único thread, você pode se safar sem utilizar mutexes.

Loading…

No matching activity found.

Browse all component changes

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect2/para
Source string location
article.translate.xml:801
String age
a year ago
Source string age
a year ago
Translation file
articles/pt_BR/geom-class.po, string 149