естественно не относится, но обработчик выполняется в контексте процесса и после его завершения процесс продолжит работу если бы обработчик вообще не имел никакой связи с прерванным процессом (т. е не выполнялся в его контексте), то каким образом был бы реализлван возврат к его выполнению мне кажется это настолько очевидным, что я не понимаю, о чем здесь можно спорить в Linux никогда не применялась аппаратная многозадачность по поводу стека в реализации Linux для x86 в TSS валиден один ESP0 и TSS один (на MP-системе их количество равно количеству логических процессоров), при переключении контекста в ESP0 записывается адрес стека ядра процесса, которому передается управление что-то в этом есть к слову, в реализации Linux для x86-64 именно такой подход (не совсем такой, но принцип такой же) и используется для каждого процессора создается структура PDA (Processor Descriptor Area) и адрес этой структуры помещается в его регистр GS получение адреса thread_info сводится к двум инструкциям Код (Text): mov eax, qword [gs:OFFSET] ; адрес вершины стека ядра sub eax, 8192 ; thread_info но такой подход оправдан, когда есть быстрая инструкция получения базы GS типа swapgs даже если строка с нужными данными будет находится в L1, а в TLB будет физический адрес страницы все равно, имхо, выполнение двух операций с регистрами будет быстрее, чем выполнение инструкции с адресным операндом в Linux для x86-64 такой подход применяется по двум причинам: а) наличие swapgs б) унификация работы int 0x80, sysenter и syscall даже сразу после перехода на нулевое кольцо стек уже не пуст не понимаю, как тут реализовать ожидание поясните на примере pause() (ожидание прихода сигнала) программа выполняет, к примеру, int 0x80 для вызова системного сервиса sys_pause() что дальше? хорошо, допустим мы делегировали обработку какому-то мифическому потоку а делегирующему процессу что тогда делать? возврат-то на третье кольцо невозможен, потому что обработка не завершена бесконечный цикл? так рано или поздно планировщик все равно вытеснет процесс (истечет квант времени) запретить вытеснение? тогда не на MP-системе произойдет полное зависание других процессов стремно мы просто по-разному понимаем понятие контекст ну у меня сейчас 80 (включая все процессы из группы потоков, а не только лидера из этой группы) а максимальное количество недетерминировано чем больше ресурсов (в частности паамяти), тем больше процессов в плане реализации потоков Linux более "микроядерная" ОС хотя бы потому, что ядро "знает" о только лишь самых фундаментальных примитивах все остальное - библиотека пользовательского уровня в Windows же поток - отдельная концепция на уровне ядра угу а что сложного? если учесть, что ОС - по определению не калькулятор важным показателем является и общий размер образа ядра на диске у меня он 1.6M мало, не правда ли? что-то сразу вспомнил про public-наследование is-a а я и не имел в виду под объективно лучшей читаемостью эти конструкции Код (Text): *(*a * *b * *c)
SII давай отринем от лирики про читабильность, ибо это абсолютная субъетивность порождает портянки флудотопа) а рассмотрим вопрос с позиции теор. множеств: итак, всякий яву является подмножеством унивёрсума по имени асм - так ответь на вопрос: какой язык си или паскаль порождает большее колво разл-ых бинарников равных по функционалу???
не надо человек очень хорошо излагает свои мысли и пустой воды нету и читать приятно в отличие от многих других авторов (я не имею в виду кого-то конкретно)
rei3er согласен на все 100: как можно уместить в одну строчку то, что, как минимум, требует 1000 строк)
SII Я не аргументирую многое, да. Все это миллион раз было обговорено. И миллион первый - для каждой задачи свой инструмент. //---- Я не верю, что с вашей стороны существует непонимание вопроса. Посему мне кажется, что это стеб. Правда красивый. //---- Только это. Про Паскаль бред, могу точно сазать. Ада - да. Но ПО - это одно, а ОС под которым оно работает - разные вещи. Хотя применительно к бортовым системам, само представление ОС довольно необычно. Слов не хватает. Не могу отличить, что поделать Извините, но во первых, компилятор С++, производят не только мелкомягкие. Во вторых, не стоит всоминать 6 студию. Сейчас их компилятор и стандарты поддержвает и ошибок в нем стало значтельно меньше (не скажу чо не стало - потому как ошибки есть везде). И вообще меня начинает раздражать подробные рассуждения. Что другие компиляторы безгрешны? На этом все, стеб закончен. //------------- Одно не могу понять, что пытаемся доказать? Что С - самый ужасный язык? Давайте альтернативы. Не считайте людей за неразумных. Предложте альтернативы, покажите что на этих альтернативах сделано, или собираются сделать. От хорошего никто не отказывается А то пока мы обливаем то что сделано. Что легко. Ничего не предлагая взамен для критики. Только если бы на допустим Паскале была бы написана Ось - это была бы супер Ось. В отличие от того г...а которое есть. //------------- Но впрочем мои комплементы, пишешь отлично.
кончаем флуд. Щас тему закроют. ОСевые и Языковые войны уже не в моде. Кстати, а почему тут 98% человек не любят Java? Интерпретируемость? Если железо хорошее и есть навыки управления ресурсами (только не надо мне говорить, что GarbageCollector делает все за нас - отправлю в цех по выпрямлению рук), то эта причина отпадает. Что же тогда? Может хватит спорить на эти темы? Я болле чем уверен, не малая часть кодеров, утверждающих, что знают JAVA и могут о ней судить, не смогут нормально справиться с механизмами Reflection и EntityManagement ( a.k.a. Persistence), а люди, говорящие, что NT хуже чем UNIX не знают ни той ни другой системы. Я хоть и линуксоид, но считаю Windows достаточно хорошей системой.
device а он и нафиг не нужен, ибо вопрос сборки мусора может решаться парсером кода перед компиляцией
UbIvItS Я просто видел убойный код: Был класс Abstract_Object в котором переопределен деструктор следующим образом : Код (Text): protected void finalize() { Runtime.getRuntime().gc(); } Все остальные классы в проге глухо наследовались от AbstractObject. То есть человек ваще документацию не читал, или... в общем, слов нет! Приходишь к соседу: Брат, дай 100 р. Он тебе - На! Ты ему: Спасибо... и пулю в лоб.
rei3er +1 Закругляемся. Если по теме - Neckromancer, программируй по велению сердца под ту систему, которая больш по душе. Я по философии кодю под никсы, но и от винды не отказываюсь. Раньше была такая дилемма, теперь давно отмерла. Тема исчерпана.
но я всё же последние пять копеек брошу) си == позволяет большим кол-вом способов решить задачу, что и делает его более близким к асму нежели другие яву. паскаль == более структурирован и больше подходит для прикладных задач, так что я сильно сомеваюсь, что свет увидит ос на паскале) -------- короче, и си, и паскаль - хорошие вещи. нет плохих инструментов - есть плохой выбор и реализация)
reverser dolzhen izuchat/ znat i razbiratsya vo VSEM!!! i ne ostanavlivatsya, posle linuxa perehodi na macintosh, symbian etc.
Headerx 1. Реверсер никому ничего не должен, ибо ОН реверсер. Это ему все должны ))) 2. ВСЕ ЗНАЮТ только ламеры.
Headerx правильно сказал..не нужно останавливаться..нужно все время изучать что-то новое для себя..это же всё так интересно..
zen на всё нужны силы и время, и не только для того, чтобы приобретать новые знания, но ещё и для того, чтобы поддерживать работоспособность уже имеющихся) есть пословица: перед собой надо ставить реальные цели, а для нереальных есть исполнители)