Согласен, это говнокод. Можно было хотя бы попытаться определить причину первой ошибки, и пытаться удалять второй раз после задержки. А вообще, для подобных ситуаций, есть понятия таймаута и числа повторов.
Сразу видно, человек имел дело с реальными задачами.
А ещё очень интересны механизмы сквозного «склеивания» свойств в БД, слое бизнес-логики и представления. Когда одна и та же вещь и в БД, и в контроллере и в GUI называется одинаково. А то в enterprise-приложениях, чтобы добавить или изменить единственный «атрибут», приходится изменять массу кода и «пробрасывать» его через все слои абстракции. Имели опыт реализации подобной «серебрянной пули»?
У монстров рынка обычно свои идеи, и на гаражные стартапы они не обращают внимания, пока те не станут гуглом или майкрософтом…
Поддерживаю автора в открытости миру своими идеями! Иначе никогда не реализуешь, отпугивая потенциальных партнёров (и друзей!) своими талмудами NDA…
Если понимать асинхронность именно так, то, да, без многопоточности не обойтись. Но, боюсь, вы запутались в терминологии — хотя мне безразлично, как называть вещи (ну, не обязательно же своими именами, правда? :-)
Предлагаю перестать здесь флудить и пообщаться в личке.
Можно и в том же потоке, если у вас что-нибудь вроде SQLite. Можно и жёсткий диск читать асинхронно, по кусочку заполняя оперативку. Вот представьте, не было бы у вас операционки, не было бы готового движка БД. Например, при программировании какого-нибудь вычурного PLC-контроллера, в котором даже прерываний нет, и флеш-память можно читать непосредственно процессором, безо всякого там DMA и т.п.
Можно там асинхронный код написать, да, только он и будет нормально работать.
Прошу прощения за такой сверхъестественный пример.
При желании можно и нужно — вопрос в том, чем программа должна заниматься, пока идёт SQL-запрос. Если нужно делать что-то ещё, или сохранить отзывчивость GUI'я — то нужно, чтобы интерфейс доступа к БД поддерживал асинхронные запросы. Обычно так оно и есть. Так в чём же проблема (или задача)?
Ну почему же для тупых? Я, наверное, неясно выразился просто.
Цикл, как правило, подразумевает наличие некого фреймворка (возможно, и самописного), в котором этот самый цикл обычно вертится.
Т.е., вместо операций «скачать» пишем операции «начать качать» и «обрабатывать в таком то-месте, когда скачается». Фреймворк же внутри может «poll'ить» сетку на предмет входящих данных.
Проще GUI'ёвый пример, когда нужно развязать GUI, логику и обработку. Одного потока часто будет достаточно, если обработка разбита на маленькие куски, каждый из которых делает маленькую часть работы, а в промежутках идёт работа с GUI.
Цикл, коллбэки, маленькие операции — думаю, этого достаточно для реализации асинхронности без многопоточности.
Код становится читаемым!
А ещё очень интересны механизмы сквозного «склеивания» свойств в БД, слое бизнес-логики и представления. Когда одна и та же вещь и в БД, и в контроллере и в GUI называется одинаково. А то в enterprise-приложениях, чтобы добавить или изменить единственный «атрибут», приходится изменять массу кода и «пробрасывать» его через все слои абстракции. Имели опыт реализации подобной «серебрянной пули»?
Поддерживаю автора в открытости миру своими идеями! Иначе никогда не реализуешь, отпугивая потенциальных партнёров (и друзей!) своими талмудами NDA…
Предлагаю перестать здесь флудить и пообщаться в личке.
Можно там асинхронный код написать, да, только он и будет нормально работать.
Прошу прощения за такой сверхъестественный пример.
Цикл, как правило, подразумевает наличие некого фреймворка (возможно, и самописного), в котором этот самый цикл обычно вертится.
Т.е., вместо операций «скачать» пишем операции «начать качать» и «обрабатывать в таком то-месте, когда скачается». Фреймворк же внутри может «poll'ить» сетку на предмет входящих данных.
Проще GUI'ёвый пример, когда нужно развязать GUI, логику и обработку. Одного потока часто будет достаточно, если обработка разбита на маленькие куски, каждый из которых делает маленькую часть работы, а в промежутках идёт работа с GUI.
Цикл, коллбэки, маленькие операции — думаю, этого достаточно для реализации асинхронности без многопоточности.