Здравствуйте, AntZ, Вы писали:
SO_>>Небольшое уточнение: WaitForMultipleObject, конечно, может ждать на разных типах объектов, но, если мне не изменяет память, максимальное кол-во ожидаемых оюъектов равно 64, что никак не позволит заменить ею тот же select.
AZ> Я так-же не видел select который бы слушал более 64 дескрипторов.
Возможно, вы не писали серверного софта для обслуживания большого количества клиентов, примером может служить вебсервер. В нашей реализации нам не хватило возможностей select. AZ> Нужно например сделать тред, который ждет данные из сокета и одновременно может быть терминирован командой выданной другим тредом. Как это красиво сделать в posix? В posix невозможно одновременно сделать скажем pthread_cond_wait и select — придется сделать один из них с таймаутом и по истечении таймаута проверять другое событие, в Win32 это простой WaitForMultipleObjects
К примеру можно использовать неименованную трубу, натравить не неё читабильный конец и на сокет select и любую запись туда считать признаком терминирования.
Здравствуйте, superman, Вы писали:
S>Здравствуйте, AntZ, Вы писали:
AZ>> Я так-же не видел select который бы слушал более 64 дескрипторов. S>Возможно, вы не писали серверного софта для обслуживания большого количества клиентов, примером может служить вебсервер. В нашей реализации нам не хватило возможностей select.
хотя стоит заметить что в обоих API для этого есть свои средства
S>Возможно, вы не писали серверного софта для обслуживания большого количества клиентов, примером может служить вебсервер. В нашей реализации нам не хватило возможностей select.
Тред не обязательно делать один, их может быть сотни или тысячи, вероятно Вы выбрали специфичную архитектуру с "супертредами". Можно сделать сто тредов, каждый из которых будет запускать select.
S>К примеру можно использовать неименованную трубу, натравить не неё читабильный конец и на сокет select и любую запись туда считать признаком терминирования. :shuffl
А если тредов тысяча? Надо сделать тысячу труб и посылать сто команд терминирования? pthread_cond_brоadcast — выглядит заманчиво, но как быть с тредами которые висят на блокирующих вызовах? WaitForMultipleObjects раз и навсегда решает эту проблему.
Я не считаю, что Win32 рулезней posix или наоборот. Есть и контрпримеры, когда красивый код на посиксе выростает в уродство на Win32
Здравствуйте, AntZ, Вы писали:
S>>Возможно, вы не писали серверного софта для обслуживания большого количества клиентов, примером может служить вебсервер. В нашей реализации нам не хватило возможностей select.
AZ>Тред не обязательно делать один, их может быть сотни или тысячи, вероятно Вы выбрали специфичную архитектуру с "супертредами". Можно сделать сто тредов, каждый из которых будет запускать select.
такая архитектура используется, например, в GHC — дегковесные потоки, весь I/O идёт через один настоящий thread, в котором используется select. правда про ограничение в 64 операции я никогда не слышал
Здравствуйте, AntZ, Вы писали:
A>>Давай скажем так: Мне доводилось давать верхний край указываемой вилки на старт, и один раз даже больше. Да для этого действительно нужно много знать, и создать впечатление что можешь много делать, но вообщем для этого не нужно даже быть человеком из мира поисковых систем.
AZ>Не верю (C) Станиславский. AZ>Яндекс. Разработчик поиска 2.0 (58-94). AZ>В нижнюю планку (58) — верю, это среднерыночная ЗП. Верхняя (94) — это как раз "заманиловка", которая используется для привлечения потока резюме.
Не верь. Тем не менее это правда. Да ее совсем не 100% людей получают.
AZ>Наличие одного-двух исключений лишь подтверждает правило.
Как ты ты очень странно аргументы используешь, все опровергающее объявляем исключением и считаем аргументом в свою пользу. Нет извини, но это аргумент в мою пользу. Я представляю себе легко за что я готов предлагать эти деньги. 120 я например предлагать не готов (почти) ни в каком случае поэтому ее не пишу. 94 готов — предлагал — пишу.
AZ>при средних ЗП и проектах далеких от "ракетных технологий".
ты уж определись все-таки для себя 94 это средняя зарплата или нет.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, AntZ, Вы писали:
S>>Возможно, вы не писали серверного софта для обслуживания большого количества клиентов, примером может служить вебсервер. В нашей реализации нам не хватило возможностей select.
AZ>Тред не обязательно делать один, их может быть сотни или тысячи, вероятно Вы выбрали специфичную архитектуру с "супертредами". Можно сделать сто тредов, каждый из которых будет запускать select.
Обычно все-таки тредов сильно больше чем ядер не запускают. А вот соединений как правило действительно тысячи.
S>>К примеру можно использовать неименованную трубу, натравить не неё читабильный конец и на сокет select и любую запись туда считать признаком терминирования. :shuffl
AZ>А если тредов тысяча? Надо сделать тысячу труб и посылать сто команд терминирования? pthread_cond_brоadcast — выглядит заманчиво, но как быть с тредами которые висят на блокирующих вызовах? WaitForMultipleObjects раз и навсегда решает эту проблему.
Если тредов тысяча то WaitForMultipleObjects как раз эту проблему не решает. Он только с 64.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
A>Обычно все-таки тредов сильно больше чем ядер не запускают. А вот соединений как правило действительно тысячи.
Это новое слово в программировании. Наверное на CoreDuo лучше запускать только два треда Вот создатели скажем Oracle настолько тупы, что не способны сделать двухтредовый дизайн Вот к примеру типовой список тредов/процессов Oracle:
PMON
DBW0
LGWR
CKPT
SMON
RECO
SNP0
SNP1
Не правда ли, тупой дизайн? Гораздо больше чем ядер в моем компутере. У меня сейчас на голой винде около 30 процессов и сотни тредов.
A>Если тредов тысяча то WaitForMultipleObjects как раз эту проблему не решает. Он только с 64.
Вы ответили не на тот вопрос. Если у меня есть тысяча тредов и каждый висит на WaitForMultipleObjects, то все треды могуть быть "разбужены" одним SetEvent, при этом каждый тред может ждать и другие события. В posix WaitForMultipleObjects нет, там тред не может ждать несколько независимых событий разных типов. Как дать команду треду закончить работу, если он скажем висит на select? А если на pthread_mutex_lock? А в винде можно параллельно ждать лока мьютекса и ивент на завершение работы — любое событие разблокирует тред моментально.
Здравствуйте, AntZ, Вы писали:
A>>Обычно все-таки тредов сильно больше чем ядер не запускают. А вот соединений как правило действительно тысячи.
AZ>Это новое слово в программировании. Наверное на CoreDuo лучше запускать только два треда Вот создатели скажем Oracle настолько тупы, что не способны сделать двухтредовый дизайн
Oracle блокируется очень много на дисковых операциях — к http серверу это относится существенно меньше. Посмотри например как nginX устроен, или lighttpd.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
V_>Одно радует — ни первое ни второе не практикуется в передовых компаниях. Может, это одна из причин того, что они передовые ?
Укажите, пожалуйста, список передовых компаний. Интересно знать, где обещают "многаденех" и их выплачивают сразу же пришедшим кандидатам.
В реальности, вилка зарплат указывается обычно "от" и "до". Так вот, суммы вроде $4000 за С++ программистов — это таки не "от", а "до", и если на собеседование придет Страуструп, то, пожалуй, он влёгкую докажет, что стоит этих 4.000. Но в реальности обычно приходят очень распальцованные чайники, которые, увы, С++ не знают, не представляют, чем red-black tree отличается от AVL, не могут обосновать выбор контейнера а уж про алгоритмы STL и вовсе не слышали. Но хотят верхнюю планку.
Поясню, зачем ставят солидные суммы: чтобы слабые кандидаты заведомо постеснялись ходить на собеседования. Правда, не уверен, достигается ли данный эффект.
A>Если тредов тысяча то WaitForMultipleObjects как раз эту проблему не решает. Он только с 64.
Надеюсь, религия не запрещает использовать I/O completion routines и WaitForMultipleObjectsEx() ?
Что бы там не писали убеждённые юниксоиды, после трех лет кроссплатформенных разработок я окончательно убедился в том, что среда Windows намного более friendly к разработчику user-level софта. А вот с kernel, пожалуй, ситуация обратная, но чисто из-за того, что в windows нет открытых исходников.
Здравствуйте, SomeOne_TT, Вы писали:
SO_>Приглашают собеседоваться в Яндекс-Деньги на позицию дельфи-программиста, Питер. SO_>(http://company.yandex.ru/inside/job/programmer.xml)
SO_>Чего можно ожидать в плане зарплаты?
Могу сказать чего можно ожидать в плане собеседования
Нужно быть очень очень быстрым программером . Приготовься порешать задачку на которую в реальности уйдет неделя за пару часов. При чем это будет задача не на сообразительность , а именно такая достаточно объемная по коду программа . Я лично таких Quick-программеров в жизни не видел , видимо они все в яндекс-деньгах работают.
Ну в принципе это наверное и хорошо что вот так вот сразу бьют молотком по башке . За то точно понятно можешь ли ты в таком режиме кодить или нет . Меня бы лично хватило так напрячься только на кратковременный промежуток времени может раз в два месяца . А судя по тому как они подают эти задачки , это типа рутина у них , вот так вот на раз за пару часов пару тыщ строк хорошо структурированного оптимизированного на низком уровне кода выдать .
Здравствуйте, sined, Вы писали:
S>Ну в принципе это наверное и хорошо что вот так вот сразу бьют молотком по башке . За то точно понятно можешь ли ты в таком режиме кодить или нет . Меня бы лично хватило так напрячься только на кратковременный промежуток времени может раз в два месяца . А судя по тому как они подают эти задачки , это типа рутина у них , вот так вот на раз за пару часов пару тыщ строк хорошо структурированного оптимизированного на низком уровне кода выдать .
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, sined, Вы писали:
S>>Ну в принципе это наверное и хорошо что вот так вот сразу бьют молотком по башке . За то точно понятно можешь ли ты в таком режиме кодить или нет . Меня бы лично хватило так напрячься только на кратковременный промежуток времени может раз в два месяца . А судя по тому как они подают эти задачки , это типа рутина у них , вот так вот на раз за пару часов пару тыщ строк хорошо структурированного оптимизированного на низком уровне кода выдать .
_O_>А что хоть за задача такая ?
Я в деталях не вспомню уже но что то типа редактора последовательностей списков байтовых последовательностей с MDI интерфейсом, ну и объем данных вроде как не ограничен. Вообщем в спокойных домашних условиях задача делается за день два , если промышленным образом я бы положил неделю . Но в условиях чужого офиса на собеседовании по крайней мере для меня за пару часов такое путно написать unreal. В принципе во многих конторах дают такого плана задачи дома поделать ничего сложного.
Здравствуйте, sined, Вы писали:
S>Я в деталях не вспомню уже но что то типа редактора последовательностей списков байтовых последовательностей с MDI интерфейсом, ну и объем данных вроде как не ограничен. Вообщем в спокойных домашних условиях задача делается за день два , если промышленным образом я бы положил неделю . Но в условиях чужого офиса на собеседовании по крайней мере для меня за пару часов такое путно написать unreal. В принципе во многих конторах дают такого плана задачи дома поделать ничего сложного.
Т.е. просто 16-й редактор написать требовалось ? Я в GUI-ях не силен, потому не уверен сколько времени на front-end уйдет. Но back-end этого за пару часов сделать не проблема. Даже быстрее можно.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, sined, Вы писали:
S>>Я в деталях не вспомню уже но что то типа редактора последовательностей списков байтовых последовательностей с MDI интерфейсом, ну и объем данных вроде как не ограничен. Вообщем в спокойных домашних условиях задача делается за день два , если промышленным образом я бы положил неделю . Но в условиях чужого офиса на собеседовании по крайней мере для меня за пару часов такое путно написать unreal. В принципе во многих конторах дают такого плана задачи дома поделать ничего сложного.
_O_>Т.е. просто 16-й редактор написать требовалось ? Я в GUI-ях не силен, потому не уверен сколько времени на front-end уйдет. Но back-end этого за пару часов сделать не проблема. Даже быстрее можно.
Возможно для кого как , я вот лично не могу за пару часов.
Здравствуйте, sined, Вы писали:
_O_>>Т.е. просто 16-й редактор написать требовалось ? Я в GUI-ях не силен, потому не уверен сколько времени на front-end уйдет. Но back-end этого за пару часов сделать не проблема. Даже быстрее можно.
S> Возможно для кого как , я вот лично не могу за пару часов.
Ну если предположение верно и это 16-ий редактор, то на нижнем уровне нам нужно:
— некий буффер, в который будет отображаться кусок файла. Сей буфер нужно уметь гонять по файлу. Прокрутка в окне будет сдвигать буфер.
— если потребно редактирование файла, то на необходим стэк операций изменения. Это позволит реализовать операции Undo/Redo
Ну а чтоб GUI быстрей сделать, надо в стандартных компонентах поковыряться. Что-то должно быть, раз задача на два часа расчитана (правда я с Delphi дело не имел)
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, sined, Вы писали:
_O_>>>Т.е. просто 16-й редактор написать требовалось ? Я в GUI-ях не силен, потому не уверен сколько времени на front-end уйдет. Но back-end этого за пару часов сделать не проблема. Даже быстрее можно.
S>> Возможно для кого как , я вот лично не могу за пару часов.
_O_>Ну если предположение верно и это 16-ий редактор, то на нижнем уровне нам нужно: _O_>- некий буффер, в который будет отображаться кусок файла. Сей буфер нужно уметь гонять по файлу. Прокрутка в окне будет сдвигать буфер. _O_>- если потребно редактирование файла, то на необходим стэк операций изменения. Это позволит реализовать операции Undo/Redo
_O_>Ну а чтоб GUI быстрей сделать, надо в стандартных компонентах поковыряться. Что-то должно быть, раз задача на два часа расчитана (правда я с Delphi дело не имел)
Несколько сложнее чем просто 16-ий редактор , файл имеет формат списка списков , то есть надобно поддерживать формат еще + буфферизация — это бекенд, + MDI интерфейс фронтенд .
