страниц на 600, хочу читать, а не писа́ть (для того, чтобы писа́ть у меня не хватает денег, писательство коммерчески неэффективно). Разделы книги:
Глава 1) история вопроса, история названия, выбор названия, выбор сокращения
отображение файлов в память (ОФП)
определить объект изучения, методы изучения, цели изучения и что там ещё бывает в научном подходе.
Глава 2) задумка, сценарии использования ОФП
Глава 3) Логическая модель ОФП и понятия, используемые в ней.
Глава 4) АПИ, который позволяет манипулировать (выполнять действия и операции) логическими объектами логической модели.
(то есть, переложение онтологии ФОП на терминологию объектно-функционального программирования)
4.1) отличие от модели работы с потоками, которой учат всех (System.IO)
Глава 5) Использование в технологиях
5.1) C#
5.1.1) Сведение к синтаксису конкретного языка
5.1.2) Поддержка в рантайме технологии
5.2) Rust
5.3) Си
5.4) Java
5.5) haskell
Глава 6) Реализация механизма в ядре операционной системы
6.0) Понятие файла вообще
6.0.1) Понятие потока
6.0.2) Отличие файлов от потоков
6.1) Linux
6.1.1) Какие особенности в Android? Сравнение с местными механизмами IPC
6.2) Windows
7) архитектура процессора, которая делает возможным такое отображение
Глава 8. Практическое использование
8.1) почему MMF быстрее Named Pipes в качестве IPC
8.2) бывают ли мэппинги памяти с дескрипторами файлов, но без файлов на диске?
8.3) реализация связи между SQL-клиентом и Microsoft SQL-сервером (вообще оно называется там Shared Memory, а не MMF, это сильно критично?) в качестве примера использования
8.4) Использование MMF при редактировании текстовых файлов (как удлинить)
8.5) Неудобство stdin (это stream, который не может быть MMF в общем случае)
(и как с таким бороться в операционных системах будущего)
8.6) Другие сценарии, примеры
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Memory-Mapped Files in a Nutshell
А зачем? слишком узкая тема. Нужна книга "как научиться программировать, используя stackoverflow.com".
Если серьезно, то как мне показалось, книги по программированию бесполезны, найти ответ на конкретный вопрос там не получается, только гугл. ну или если ещё есть гуру под рукой, всё разжует
wl.:
wl.> только гугл. ну или если ещё есть гуру под рукой, всё разжует
В доинтернетную эпоху программировали без всяких гуглов.
Оффлайновые справочники + бумажные книги + упорство.
Модератор-националист Kerk преследует оппонентов по политическим мотивам.
wl.>> только гугл. ну или если ещё есть гуру под рукой, всё разжует BB> В доинтернетную эпоху программировали без всяких гуглов. BB> Оффлайновые справочники + бумажные книги + упорство.
Надо идти дальше. И оформлять документацию в электронном виде, в виде сайтов сильно слинкованных.
Микрософт откровенно не справляется.
Платные авторы не будут этим заниматься, потому что легко спиратить.
Бумажные книги это такой способ защиты от копирования и способ монетизации.
Люди читают быстрее, чем воспринимают на слух.
Написание книги — это как раз и есть разжевывание конкретной темы.
Информация так и передаётся — текстами.
Здравствуйте, Bill Baklushi, Вы писали:
BB>В доинтернетную эпоху программировали без всяких гуглов. BB>Оффлайновые справочники + бумажные книги + упорство.
Все так, но это никак не оправдывает странного желания ТС. Он хочет чего-то наподобие "Техника безусловных переходов в разных языках программирования", причем в формате книги на сотни страниц, отдает маразмом.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Почему руководство на процессор Intel может иметь объём 4000+ страниц,
Он непрост.
ЭФ>а документацию на ядро Linux такого объёма иметь категорически немыслимо?
Почему немыслимо?
И зачем прыгать по темам?
ЭФ>>а документацию на ядро Linux такого объёма иметь категорически немыслимо? _>Почему немыслимо? _>И зачем прыгать по темам?
ОФП это часть стандарта POSIX, который реализуется ядром Linux.
Если всё должно быть задокументировано, то и ОФП тоже.
Написание книги оправдано.
Никому бы хуже не стало, если бы она (и ещё полсотни по другим темам) существовала.
Суммарный объём документации при этом был бы гораздо бо́льшим, чем есть сейчас.
Но его нет. И виноваты в этом такие как ты, потому что отговариваешь других людей от хороших дел.
Ну и где я по темам прыгаю? Нет? Не прыгаю? Это получается ты дважды неправ?
Тогда как настоящий процессор в случае двойного исключения ты должен уйти в перезагрузку.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>ОФП это часть стандарта POSIX, который реализуется ядром Linux.
То есть тебя интересует реализация MMF в Линуксе. Ну наверно это должна быть глава в какой-нибудь книге об архитектуре Линукса. Тем более эта тема вовсе не вещь в себе, в Винде, например, она тесно связана с другими, скажем с загрузкой образа программ, не знаю как там в Линуксе.
И при чем тут как это делается в десятке ЯП, в книжках о них и найдешь эту инфу, а в описании архитектуры Линукса должны быть примеры на Си. Всему же своё место.
ЭФ>Написание книги оправдано.
Напиши. Вот только в отрыве от описания остального устройства ОС она никому нафиг не нужна.
ЭФ>Но его нет. И виноваты в этом такие как ты, потому что отговариваешь других людей от хороших дел.
Ни от чего не отговаривал, желай что хочешь, лишь вижу что желания твои странны.
ЭФ>Ну и где я по темам прыгаю? Нет? Не прыгаю? Это получается ты дважды неправ?
Еще как прыгаешь. То у тебя использование MMF в разных ЯП, то процессоры Интел, то архитектура ОС.
ЭФ>8.1) почему MMF быстрее Named Pipes в качестве IPC
Во, понял, какую книгу я хочу.
(Сам, конечно, писать такое не возьмусь, ибо далеко не во всех аспектах обладаю достаточным уровнем знаний. Но если бы кто-то такое написал — было бы очень круто.)
Хочу книгу про IPC в широком смысле.
Чтобы в ней были собраны воедино и проанализированы разные варианты организации IPC на все случаи жизни. Чтобы были расписаны плюсы и минусы этих вариантов. И чтобы были рекомендации когда что лучше выбирать (типа сборника рецептов). Поскольку на этапе проектирования систем такая задача возникает очень часто.
Когда взаимодействие сводится только к обмену данными и когда нужна передача управления.
Когда взаимодействующие процессы/системы находятся на одной машине и когда они удалены друг от друга.
Синхронные и асинхронные варианты взаимодействия.
От самых простых вариантов (типа обмена файлами по ftp) до более продвинутых вариантов (всякие там шины, очереди сообщений и иже с ними).
Когда взаимодействующие процессы написаны на одном языке/фреймворке/стеке технологий и когда на разных.
Когда есть серьезные требования по нагрузке/быстродействию и когда таких требований нет.
Когда есть серьезные требования по транзакционной целостности и когда таких требований нет.
Когда есть серьезные требования по безопасности и когда таких требований нет.
и т.п.
Во многих книгах отдельные из этих вопросов разобраны. Но вот чтобы все это собрать, систематизировать и понятно изложить — такой книги пока не попадалось.
Здравствуйте, Эйнсток Файр, Вы писали:
wl.>> гуру под рукой, всё разжует
ЭФ>Люди читают быстрее, чем воспринимают на слух. ЭФ>Написание книги — это как раз и есть разжевывание конкретной темы. ЭФ>Информация так и передаётся — текстами.
Здравствуйте, wildwind, Вы писали:
W>Подтянуть английский не предлагать?
То есть готов предложить относительно доступную книгу на английском удовлетворяющую хотелкам ТС ?
Здравствуйте, wildwind, Вы писали:
W>В документации к ОС все можно найти, при желании.
Так не хочет ТС в документации, ни в английской, ни в русской. Ему все по очень узкой теме в одной 600 страничной книге подай, причем не только по ОС, но и по всем языкам программирования, где эта возможность. Забавляет как раз это, а не стандартно-смешное "Подтяни английский".
И да, грамотные книги на русском нужны, хоть переводные, хоть здесь написанные. Вот только у ТС очень наивное представление о их возможной тематике.
в книжках о них и найдешь эту инфу, а в описании архитектуры Линукса должны быть примеры на Си. Всему же своё место.
