<div dir="ltr"><div>@Razvan deobicei caut pe google raspunsul la astfel de intrebari.<br>Motivul pentru care nu am cautat pe google acest lucru din prima este pentru ca sunt foarte multe detalii in cartile de curs,<br>si de multe ori redefineste acelasi termen pentru alt context, si nu sunt foarte sigur de cea ce caut.<br>
</div>Intr-adevar macro-uri precum TASK_INTERRUPTIBLE fac ca contextul sa diferentieze fata de altele, dar mi s-a creat o frica<br>generala de a nu invata vreo prostie. Mai ales legat de tipuri de contexte in care poate rula un cod in kernel mi s-a creat o<br>
varza totala in cap.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-23 12:27 GMT+03:00 Catalin Vasile <span dir="ltr"><<a href="mailto:catalinvasile92@gmail.com" target="_blank">catalinvasile92@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Din ce am inteles, cand se executa un apel de sistem, acel apel de sistem se executa<br></div>
in numele procesului care l-a apelat. Din asta inteleg ca un apel de sistem poate "dormi".<br>
Daca apare un semnal catre acel proces, acesta poate trezi procesul in contextul procesarii apelului de sistem?<br></div>De asemenea, in contextul unei functii care se executa cu TASK_INTERRUPTIBLE sau TASK_UNINTERRUPTIBLE, la ce se refera cand se specifica ca acel task poate fi intrerupt sau nu? Mai exact de cine sa fie intrerupt sau nu? De intreruperile care vin catre procesor, sau de semnale primite de proces?<br>

<br>Cătă<br></div>
</blockquote></div><br></div>