Чего так? Спад завершился и наметился подъём.

https://trends.google.com/trends/explore?date=today%205-y&q=dlang - так веселее

нужно сделать бот телеграм который бы ставки принимал на курс, как на акции

тогда и заработок и курс (рейтинг) вырастет из-за ажиотажа

На D? Нет. Сложно, мутно, моторно

https://github.com/gecko0307/dagon хз

Ребятки, а тут на маке сидит кто? Кто какой ide пользуется?

Vs code

idea

Спасибо, попробую оба

Package dash version 0.12.0-beta2 - DUB - The D package registry https://code.dlang.org/packages/dash

https://github.com/gecko0307/dagon хз

Ещё вариант

Заброшен

и правда

https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb

Транзакции уже летом)))

Если им верить

MongoDB Drops ACID - 3 смысла у этой фразы)

MongoDB Drops ACID - 3 смысла у этой фразы)

В смысле?

Как я понимаю: - Слегка упасть вместе с ACID - ВЫбросить ACID - Закинуться "кислотой"

Заявляют, что будет работать с репликацией

А к 4.2 и с шардированием

Поживем - увидим.

а как оно так будет работать там не пишут?

Неа

Но не вижу особых проблем

Ребятки, а тут на маке сидит кто? Кто какой ide пользуется?

VScode. Попробовал идею, сублайм и атом. И смог dscanner полностью и без шаманств из коробки только на вскод и сублайм завести, но саблайм не порадовал.

Но не вижу особых проблем

https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP но ведь...

В реплике не вижу особых проблем

С шардированием, конечно, гораздо больше проблем

В реплике не вижу особых проблем

хвалёная монговая скорость уйдёт

Возможно. Но только при реплики

И то не факт)

Будет видно, как выйдет

надо код новый глядеть

VScode. Попробовал идею, сублайм и атом. И смог dscanner полностью и без шаманств из коробки только на вскод и сублайм завести, но саблайм не порадовал.

Класс, спасибо ?

Ух нафигачил вчера отличный кольцевой буфер )) Часов 7 сидел

Ух нафигачил вчера отличный кольцевой буфер )) Часов 7 сидел

Объясни, зачем он тебе?

Чтобы читать из одного сокета и писать в другой

асинхронно

Хм...

Тогда не понимаю зачем оно тебе?

Чего просто не считывать в некий буфер, а потом писать в сокет из этого буфера?

Зачем это делать циклично?

Ух нафигачил вчера отличный кольцевой буфер )) Часов 7 сидел

опубликуй?

Чего просто не считывать в некий буфер, а потом писать в сокет из этого буфера?

Потому что за одну попытку может не получиться все данные из буфера записать в целевой сокет. А на следующей итерации из источника придут еще данные, их надо куда-то дописывать.

я в цикле бегаю и ловлю события epoll - "на источник пришли данные", "целевой сокет освободился для записи". Сколько байт удастся прочитать/записать - зависит от сети и от того как звезды сложатся

опубликуй?

Хм не работает ни pastebin ни dpaste(recaptcha сломалась). Проклятый эРКаЭн

Хм не работает ни pastebin ни dpaste(recaptcha сломалась). Проклятый эРКаЭн

Это достойно code.dlang.org

https://paste.ofcode.org/4g2xZ3Ekk9WQiASZMJGZDz

Запили пакет, серьезно

Да я вот думаю, а надо ли на каждый чих пакет пилить? Может сделать как все поступают - запилить проект "мой всякий стафф" и туда коммитить )

Типа как arsd делает

я в цикле бегаю и ловлю события epoll - "на источник пришли данные", "целевой сокет освободился для записи". Сколько байт удастся прочитать/записать - зависит от сети и от того как звезды сложатся

Ну так решение на поверхности: если ты не скинул весь буфер, зачем считывать из входного соединения данные?

Жди освобождение буфера

Смысла считывать нет, так как отправить еще некому, или нет возможности

Жди освобождение буфера

Нельзя ждать, мы же работаем неблокирующе. Надо срочно бежать и обрабатывать события на других сокетах.

+ если ты считаешь весь свой буфер (скажем 100 байт), то считывать больше просто нет возможности

Т.к. ты свой циклический буфер еще не очистил

Нельзя ждать, мы же работаем неблокирующе. Надо срочно бежать и обрабатывать события на других сокетах.

Хорошо, а что ты делаешь, если твой буфер полон?

Ты же пропускаешь этот сокет тогда

да

Правельней было бы его снять с мониторинга, не следить за ним, пока не появится место в буфере

Ну так вот тебе и решение: не смотреть за сокетом, пока буфер не пустой

Ну так все равно надо смотреть за сокетом в который мы пишем

Это да!

За тем ты смотришь

но за источником - без смысла

ERROR: S client not available

Ты его каждую итерацию будешь пропускать, пока буфер не освободится

Ну да, впринципе верно, однако это не отменяет нужности кольцевого буфера

И тут вопрос: какова вероятность того, что ты не успеешь очистить буфер до прихода следующего чанка?

И тут вопрос: какова вероятность того, что ты не успеешь очистить буфер до прихода следующего чанка?

Моя первая реализация как раз писала в целевой сокет весь буфер в цикле до упора. Потом я увидел что иногда приходится по 100 итераций ждать пока сокет не освободится для записи. За это время можно было обработать уже несколько других событий.

В общем писать в цикле и ждать - противоречит самой идее неблокирующей обработки.

Моя первая реализация как раз писала в целевой сокет весь буфер в цикле до упора. Потом я увидел что иногда приходится по 100 итераций ждать пока сокет не освободится для записи. За это время можно было обработать уже несколько других событий.

Это потому, что ты обрабатывал входной сокет, а сам по себе еще небыл готов к его обработке

Тебе нужно было "раздекларировать" его обработку

Нет я обрабатывал как раз выходной сокет

Ну так вот тебе и решение: не смотреть за сокетом, пока буфер не пустой

это потеря времени, т.к. пока один буфер отправляется другой может приниматься. а так ты всё время стоп-кран дёргаешь

И все

это потеря времени, т.к. пока один буфер отправляется другой может приниматься. а так ты всё время стоп-кран дёргаешь

Ну как, смотри пример:

Пришло 60 байт

твой буфер = 100 байтам

Ты считал 60 (больше просто нет)

и записываешь его во второй

но во второй записалось всего 10

И того картина:

у тебя 50 байт в буфере и что-то пришло на вход еще

Ты читаешь, а там 200 байт еще пришло

Ты вычитываешь всего 50

40 в конец и 10 в начало

И ждешь повторной попытки отправить

отправить еще нет возможности

НО тебе уже пришло еще 20 байт к тем, что еще не вычитаны 150

Все равно нужно будет "дергать стоп-кран"

это “плохой случай”. в хорошем ты принял 60 байт и поставил их на отправку и сразу втал на приём следующей порции. на следующем возврате из epoll у тебя может быть и первый буфер отправлен и новые 100 байт приняты

Иначе будет простой скип того сокета, а это и есть та реализация, что Павла была с начала. Ну практически та

это “плохой случай”. в хорошем ты принял 60 байт и поставил их на отправку и сразу втал на приём следующей порции. на следующем возврате из epoll у тебя может быть и первый буфер отправлен и новые 100 байт приняты

Да, тоже может быть

Иначе будет простой скип того сокета, а это и есть та реализация, что Павла была с начала. Ну практически та

Ваще не та )

Серебряной пули нет. Но ты или будешь делать continue каждый раз, т.к. второй сокет медленее

Блин ты все неправильно понял )

Объясни тогда еще раз :)