1) Соглашусь. Говорил же конечно про "больное"
2) В профессиональной среде, ведущие конструктора изделия обмениваются мнениями по способам решения проблемы, а решение принимает тот из ведущих, который обременен званием руководителя именно этой работы. У нас понятно - решение принимает тот, кто будет кодить. Но выслушать других - крайне важно. Ну и еще в понятие профессиональной этики безусловно входит - не обижаться на то, что принят, возможно - не твой вариант. Главное, что бы ты был понят. А обижаются - дома, а не на работе.
В общем, очень многие профессиональные правила в создании интеллектуального продукта - продуманы еще до моего рождения. Интеллектуального, это такого когда в момент начала работы успешный результат вовсе не гарантирован, а определяется как раз интеллектом разработчиков.
3) Про главное - согласен категорически.
Как я понимаю изложение эдаких мыслей - ну например так
А реализация - хоть и важный, но уже технический вопрос: можно на asm-е, можно на C, можно на паскале. Даже скажу, что там, первый (пока еще не обсуждаемый) вариант - был бы еще главнее.
4) Не, не соглашусь. Железные. Мне виднее - я как раз в том положении сегодня и нахожусь
5) Что значит помочь или не помочь. Всякие действия продиктованы какой-то целью. Да цель не настолько глобальна, как достижение всеобщего счастья... Даже сверх-мелочь: код сокращен в два раза, функциональность не изменилась, баги отысканы и прикончены. Все, цель таки достигнута, по-моему. Можно переходить к следующей, может быть и более фундаментальной, но, все-таки - также далекой от всеобщего счастья.
Перейдет ли количество в качество... Ну давай вместе думать, чтобы перешло. Сказать что такого не бывает - проще всего, но не всегда это так.
6) Ну так я и мечтаю
7) Ничем не устраивают. Тупо - никаких ассоциаций. А уж сколько раз ошибся уже...
Можно провести эксперимент. Берем свежего человека, и объясняем ему следующее:
- а) данные потока (слота) сгруппированы в структурах данных TASKDATA и APPDATA
б) тупо пропускаем мимо ушей его вопрос: а нафига в двух (это мы ему про WINDATA еще не сказали)
в) эти структуры собраны в массивы, и номер текущего слота лежит в переменной Slot_Index
г) Адреса структур в массивах, соответствующих этому индексу лежат в переменных TASKDATA_adr и APPDATA_adr
Утверждение: никогда не угадает
8 ) Вот тут начинается самое интересное, и характерное
Предположим, что у меня есть. Алгоритм не простой, но номера слотов - да хоть 32-х битные. Т.е., pid_to_slot останется, но это уже не цикл поиска, а линейный код - около десятка (не кодил еще) команд проца.
Мне следует молча начать все менять без предупреждения и разъяснений
9) Получается, не говоря ни слова, мне следует начать изничтожать в кодах все циклы с change_task. Потому что у меня возникла вот такая идея. Встретил - убил, и т.д..
Встретил 5-ю ф-ю - убил. wait_mutex - туда же относится уже автоматически. Ой, много там такого добра.
Честное слово - мало не покажется ведь
И дальше в том же духе
10) Зря убивает, имхо. Очень зря.
Не все лежащее на SVN обязано попасть в дистрибутив. Может быть и информация "для служебного пользования"
Вот я разбираюсь с vm86 по причине того, что он нахально лезет в работу shed-а
Сначала мне это казалось полным беспределом, предназначенным для безусловной ликвидации.
Теперь до меня доперло, что если не предавать управление, то и прерывания в 59-м открыть будет некому.
Но все равно, таковое вмешательство в работу shed-а может, в теории, привести к тому, что 1-й слот и управления никогда не получит...
Может там работает VIP, и надо думать как по исключеню от выхода из прерывания - вернуться в слот с которого хамски переключились...
А может и не работает - не разобрался еще.
И мне была бы бесконечно интересна авторская информация. И может быть, если "это реализовано в корне неправильно" - было бы еще интереснее. Уж точно поменяло бы направление моих (например) мыслей.