Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:


N>>>Я вот хотел сделать (на Core 5.0) чтобы коллбэки на чтение сокета срабатывали всегда в нужной нитке. Не получается: мне их, фактически, принудительно загоняют в какой-то пул, который я не просил создавать, и я должен ещё думать о мьютексах, чтобы применить их данные. А тут, наоборот, какая-то самоблокировка на одной нитке непонятно на чём.
S>> Ну тебе в данной нитке нужно организовать очередь и пихать в неё свои калбеки. Поток опять же ставить на ожидантие и при постановке в очередь выставлять эвент в сигнальное состояние.

S>Кстати да, не проще ли все организовать через блокирующую коллекцию? Пишет кто хочет, читает один поток.

S>>Либо использовать контекст синхронизации
S>>https://docs.microsoft.com/ru-ru/dotnet/standard/parallel-programming/how-to-specify-a-task-scheduler-in-a-dataflow-block

S>Интересная идея, но тут скорее выгода, если рабочих потоков может быть больше одного, а для одного городить огород
S>смысла нет. Хотя для UI сгородили.
Ну так разговор то о том, что нужно выполнить калбек в определенном потоке.
Ну организовать то свою очередь сообщений не сложно, тот же эвент с таймаутом на всякий случай.
Контекс синхоронизации это для ленивых. Ты можешь его сам создать

if (SynchronizationContext.Current == null)

            SynchronizationContext.SetSynchronizationContext(new WindowsFormsSynchronizationContext());

или System.Windows.Threading.DispatcherSynchronizationContext

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:


N>>>Я вот хотел сделать (на Core 5.0) чтобы коллбэки на чтение сокета срабатывали всегда в нужной нитке. Не получается: мне их, фактически, принудительно загоняют в какой-то пул, который я не просил создавать, и я должен ещё думать о мьютексах, чтобы применить их данные. А тут, наоборот, какая-то самоблокировка на одной нитке непонятно на чём.
S>> Ну тебе в данной нитке нужно организовать очередь и пихать в неё свои калбеки. Поток опять же ставить на ожидантие и при постановке в очередь выставлять эвент в сигнальное состояние.

S>Кстати да, не проще ли все организовать через блокирующую коллекцию? Пишет кто хочет, читает один поток.

S>>Либо использовать контекст синхронизации
S>>https://docs.microsoft.com/ru-ru/dotnet/standard/parallel-programming/how-to-specify-a-task-scheduler-in-a-dataflow-block

S>Интересная идея, но тут скорее выгода, если рабочих потоков может быть больше одного, а для одного городить огород
S>смысла нет. Хотя для UI сгородили.
Ну так разговор то о том, что нужно выполнить калбек в определенном потоке.
Ну организовать то свою очередь сообщений не сложно, тот же эвент WaitOne с таймаутом на всякий случай.
Контекс синхоронизации это для ленивых. Ты можешь его сам создать

if (SynchronizationContext.Current == null)

            SynchronizationContext.SetSynchronizationContext(new WindowsFormsSynchronizationContext());

или System.Windows.Threading.DispatcherSynchronizationContext