C setjmp.h и ucontext.h, что лучше? - PullRequest
4 голосов
/ 04 апреля 2011

Привет, мне нужно перейти с одного места на другое ...

Но я хотел бы знать, какой из них лучше использовать, setjmp или ucontext, например:

  • Являются ли setjmp и ucontext переносимыми?
  • Мой код является поточно-ориентированным при использовании этой библиотеки?
  • Зачем использовать одну вместо другой?
  • Что быстро и безопасно?
  • ... (Кто-нибудь, пожалуйста, может ответить на будущий вопрос, который я забыл здесь поставить?)

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

У меня был поиск в сети, но я получил только обработку исключений в C, как пример setjmp, и я ничего не получил о ucontex.h, я понял, что он использовался для многозадачности, в чем разницаэто и pthread?

Большое спасибо.

Ответы [ 3 ]

5 голосов
/ 04 апреля 2011

setjmp переносимо (ISO C89 и C99), а ucontext (устарело в SUSv3 и удалено из SUSv4 / POSIX 2008) - нет. Однако ucontext был значительно более мощным по спецификации. На практике, если вы использовали неприятные хаки с setjmp / longjmp и обработчиками сигналов и альтернативными стеками обработки сигналов, вы могли бы сделать их примерно такими же мощными, как ucontext, но они не были «переносимыми».

Ни один из них не должен использоваться для многопоточности. Для этого используются потоки POSIX (функции pthread). У меня есть несколько причин сказать это:

  • Если вы пишете многопоточный код, вы также можете заставить его работать одновременно. Мы достигли ограничения скорости непараллельных вычислений, и будущие машины будут становиться все более и более параллельными, поэтому воспользуйтесь этим.
  • ucontext был удален из стандартов и может не поддерживаться в будущих ОС (или даже в некоторых существующих?)
  • Прокрутка собственных потоков не может быть прозрачной для библиотечного кода, который вы, возможно, захотите использовать. Это может нарушить библиотечный код, который делает разумные предположения о параллелизме, блокировке и т. Д. Пока ваша многопоточность является кооперативной, а не основанной на асинхронном сигнале, вероятно, таких проблем не так уж много, но как только вы углубитесь в непереносимость взломать вещи могут стать очень хрупкими.
  • ... и, возможно, еще несколько причин, о которых я не могу думать сейчас. : -)
0 голосов
/ 04 апреля 2011

Что касается переносимости, setjmp() является переносимым для всех размещенных реализаций C; <ucontext.h> функции являются частью расширений XSI для POSIX - это делает setjmp() значительно более портативным.

Можно использовать setjmp() потокобезопасным способом. Не имеет смысла использовать функции ucontext в многопоточной программе - вы бы использовали несколько потоков, а не несколько контекстов.

Используйте setjmp(), если вы хотите быстро вернуться из глубоко вложенного вызова функции (вот почему вы обнаружите, что большинство примеров показывают его использование для обработки исключений). Используйте функции ucontext для реализации потоков или сопрограмм в пространстве пользователя (или вообще не используйте их).

«Быстрый и безопасный» вопрос не имеет смысла. Реализации, как правило, выполняются настолько быстро, насколько это практически возможно, но они выполняют разные функции, поэтому их нельзя сравнивать напрямую (функции ucontext выполняют больше работы, поэтому обычно будут работать немного медленнее).

Обратите внимание, что функции ucontext перечислены как устаревшие в двух последних выпусках POSIX. Вместо этого обычно следует использовать функции потоков pthreads.

0 голосов
/ 04 апреля 2011

setjmp / longjmp предназначены только для восстановления «вызывающего» контекста, поэтому вы можете использовать его только для «быстрого выхода» из цепочки подпрограмм.Различное использование может работать, а может и не работать, в зависимости от системы, но в целом эти функции не предназначены для такого рода вещей.Так что "UContext" лучше.Также обратите внимание на «волокна» (родной для Windows).Вот ссылка на статью, которая может быть полезна:

Как реализовать практический оптоволоконный планировщик?

Пока!

...