Есть ли будущее у DELPHI?

Цитата korvin @ 27.10.12, 19:00

И какие отличия это дает?

А что для тебя есть отличия?

Ну все, уже философия пошла

MyNameIsIgor, все, я просек как это работает, код async-метода выполняется синхронно с остальным до await. Т.е. если в

func test() {
  sleep(1s)
  print("test")
  foo()
  bar()
}
 
func main() {
  go test()
  print("main")
}

«main» напечатается до «test», то в

async void test() {
  sleep(1s)     // 1
  print("test") // 2
  sleep(1s)     // 3
  await foo()   // test ожидает, main продолжает работать
  await bar()
}
 
void main() {
  test()
  print("main") // 4
}

действия выполнятся в указанной последовательности.
Так? Мой наспех сделанный тест это подтверждает =)

Добавлено 27.10.12, 19:23

Цитата MyNameIsIgor @ 27.10.12, 19:06

А что для тебя есть отличия?

Ну, последовательность выполнения кода, что гарантируется, а что нет.

Добавлено 27.10.12, 19:25

Цитата D_KEY @ 27.10.12, 19:17

Ну все, уже философия пошла

Ну так, неисповедимы пути микрософта =)

Сообщение отредактировано: korvin - 27.10.12, 19:25

Цитата D_KEY @ 27.10.12, 19:17

Ну все, уже философия пошла

Обоснуй. Я не вижу здесь никакой философии.

Цитата korvin @ 27.10.12, 19:22

MyNameIsIgor, все, я просек как это работает, код async-метода выполняется синхронно с остальным до await.

Да. Всё остальное идёт в коллбэк. Если взять такой код

async void foo(SomeType s)
{
  var task = await SomeTask();
  s.field = "foo";
}
 
var s = new SomeType();
foo(s);
// здесь нам нужна синхронизация для s

Такого эффекта нет в том же boost.task. Если же мы будем ждать окончания выполнения foo, то заблокируем весь поток.

Цитата

Я думал для этого код просто выносят в отдельные потоки...

Это подход конца 90-х... начала 2000-х. Ещё не все, видимо, поняли всю порочность потоков.
Плюсов у потоков несколько:
1) быстрая синхронизация критическими секциями (под виндой).
2) не надо думать
3) можно сделать вид, что всё работает, хотя оно на самом деле, жутко тормозит, например, есть какой нибудь gethostbyname, ну вот если у тебя долбанутый DHCP, или просто проблемы с соединением - может быть зависание. Надолго. Скажем, на минуту. Или, скажем, открытие какой нибудь очень большой SQLITE базы. И вот что бы GUI не тормозило, когда у нас все висит...

Но на самом деле эти плюсы не очень велики.
1) синхронизацию нужно применять только в крайних случаях. Если у нас всего один поток - синхронизация вообще не нужна.
2) код превращается в ад, побочные race-condition и другие подобные прелести, которые очень сложно поймать и отладить.
3) это от того, что существуют старые (и, зараза, удобные) синхронные API. Если их не использовать - то этого плюса вообще не существует.

Сообщение отредактировано: Бобёр - 28.10.12, 09:43

Цитата Бобёр @ 28.10.12, 09:43

можно сделать вид, что всё работает, хотя оно на самом деле, жутко тормозит, например, есть какой нибудь gethostbyname, ну вот если у тебя долбанутый DHCP, или просто проблемы с соединением - может быть зависание. Надолго. Скажем, на минуту. Или, скажем, открытие какой нибудь очень большой SQLITE базы. И вот что бы GUI не тормозило, когда у нас все висит...

Едрить через коромысло... А что, вышеперечисленное и правда пишут в обработчике on_click?

Цитата Бобёр @ 28.10.12, 09:43

не надо думать

О чем?

Цитата Бобёр @ 28.10.12, 09:43

можно сделать вид, что всё работает, хотя оно на самом деле, жутко тормозит, например, есть какой нибудь gethostbyname, ну вот если у тебя долбанутый DHCP, или просто проблемы с соединением - может быть зависание. Надолго. Скажем, на минуту. Или, скажем, открытие какой нибудь очень большой SQLITE базы. И вот что бы GUI не тормозило, когда у нас все висит...

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

Цитата Бобёр @ 28.10.12, 09:43

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

Асинхронность бывает и в одном потоке.

Цитата Бобёр @ 28.10.12, 09:43

код превращается в ад, побочные race-condition и другие подобные прелести, которые очень сложно поймать и отладить.

При таком дурацком подходе к организации асинхронного кода как в C# -- возможно. Но есть и более лучшие решения.

Цитата Бобёр @ 28.10.12, 09:43

это от того, что существуют старые (и, зараза, удобные) синхронные API. Если их не использовать - то этого плюса вообще не существует.

Это предложение в контексте предыдущих я не понял.

Цитата MyNameIsIgor @ 28.10.12, 10:14

А что, вышеперечисленное и правда пишут в обработчике on_click?

Я видел подобное в рабочем ПО, не буква в букву, но очень похоже.

Цитата Бобёр @ 28.10.12, 09:43

Это подход конца 90-х... начала 2000-х. Ещё не все, видимо, поняли всю порочность потоков.

Но тут очень важно - как именно организована асинхронность. Если на базе скрытого пула потоков с коллбэками - то всё вышеперечисленное в "минусах" остаётся верным, потому что тебе надо быть очень аккуратным, когда эти самые коллбэки пишешь. Если на базе событийной модели, когда уведомления приходят в главный поток, то чуть проще, но медленнее и тоже надо быть аккуратным.

Сообщение отредактировано: Flex Ferrum - 29.10.12, 07:56

Цитата

Но тут очень важно - как именно организована асинхронность. Если на базе скрытого пула потоков с коллбэками - то всё вышеперечисленное в "минусах" остаётся верным, потому что тебе надо быть очень аккуратным, когда эти самые коллбэки пишешь.

В WinRT вроде бы именно этот подход. Если GetThreadID() мне не врет. Документацию читать лень.

Сообщение отредактировано: Бобёр - 29.10.12, 18:22

Цитата Бобёр @ 29.10.12, 18:21

В WinRT вроде бы именно этот подход. Если GetThreadID() мне не врет. Документацию читать лень.

Ну тады это поле непуганных и нехоженных граблей.

Хм.. ну посмотрим.

Цитата Бобёр @ 30.10.12, 06:58

Хм.. ну посмотрим.

А что. Бери простой сценарий: одна и та же callback-функция вешается на две асинхронных активности. В функции производится обращение к некоей переменной. Несинхронизированное. В просторечье это называется "гонки". Можешь оценить вероятность такого сценария при условии, что программить будет чел, который знает про асинхронность, но не знает про потоки?

Эти асинхронные таски устроены примерно так. На вход ты передаёшь какие то данные (лучше копии ), таска работает в контексте другого потока и поэтому ЛУЧШЕ не синхронизированно какие то данные основного потока не трогать. Если трогаешь - приготовься к .. ээ.... ХУДШЕМУ. Однако в самой таске после ключевого слова then мы уже находимся В ОСНОВНОМ ПОТОКЕ, и уже можно из самой таски трогать основные данные НЕ СИНХРОННО! BINGO! Т.е. это по сути такая очень прикольная обёртка над старым добрым потоком, только не надо заниматься каждый раз мастурбациями в стиле

resultData->DeleteByReceiver(TRUE);
PostMessage(hMain, MY_MSG_EVERYTHING_IS_OK, (LPARAM)(resultData), (WPARAM)myTaskId);

Сообщение отредактировано: Бобёр - 31.10.12, 06:43

Цитата Бобёр @ 31.10.12, 06:40

Однако в самой таске после ключевого слова then мы уже находимся В ОСНОВНОМ ПОТОКЕ

Всё же это зависит от настройки пула. Так, как вы описали, происходит в гуишных приложениях, потому что там из основного потока происходит вызов обработчиков событий, которые таки делают return обратно.
А как вы себе представляете запуск коллбэка всегда из основного потока, если это не обработчик, вызванный откуда то, а самый что не есть main? Будете останавливать поток чёрт знает в какой момент, подменять ему контекст, запускать... мрак... а если этот самый главный поток в этот момент мютексами с другими потоками синхронизируется, ууууууу....