Существует ли эквивалент UNIX/pthreads событиям сброса руководства Windows?
В Windows можно зарегистрировать другие языки в Хосте Сценариев и иметь их в наличии для IE. Например, VBScript поддерживается из поля (хотя это никогда не получало много популярности, как это в большинстве целей, еще хуже, чем JavaScript).
расширения Python win32 позволили добавлять Python к IE как это довольно легко, но это не была действительно хорошая идея, поскольку Python довольно трудно поиграть в песочнице: много функций языка представляют достаточно рычагов реализации, чтобы позволить предположительно-ограниченному-приложению вспыхивать.
Это - проблема в целом это, чем больше сложности Вы добавляете к стоящему с сетью приложению как браузер, тем большая вероятность проблем безопасности. Набор новых языков, конечно, соответствовал бы тому описанию, и это новые языки, которые также все еще разрабатывают быстро.
JavaScript является ужасным языком, но посредством тщательного использования выборочного подмножества функций и поддержки со стороны подходящих библиотек объектов, это может обычно делаться довольно терпимым. Кажется, что возрастающие, практические дополнения к JavaScript являются единственным способом, которым, вероятно, будут идти дальше веб-сценарии.
2 ответа
Это только для Linux (я упоминаю об этом только потому, что у вас есть тег "linux"), но я думаю, что вы могли бы создать что-то подобное на системном вызове futex . См. статью Ульриха Дреппера о фьютексах для получения подробных сведений.
Очень грубо, я предполагаю что-то вроде
void inline gate_wait(volatile int *gate)
{
if (*gate)
while (futex(gate, FUTEX_WAIT, 1, 0, 0, 0) == EINTR)
;
}
int inline gate_open(volatile int *gate)
{
*gate = 0;
return futex(gate, FUTEX_WAKE, INT_MAX, 0, 0, 0);
}
void inline gate_close(volatile int *gate)
{
*gate = 1;
}
. Если вы построите этот примитив синхронизации «ворот» поверх фьютексов, он может стоит добавить его в библиотеку фьютексов пользовательского пространства Расти Рассела.
Будет ли работать блокировка читателей-писателей? Я подозреваю, что это так, но вам нужно будет проверить, было ли это эффективным в тех случаях, которые вас интересуют.
См. Информацию о rwlock в http://www.opengroup.org/onlinepubs/000095399/basedefs/pthread.h.html
Любое количество считывателей, исключая только одну запись, поэтому для блокировки других потоков используйте блокировку записи. Чтобы позволить им продолжить, разблокируйте. Вам нужно будет посмотреть, какой случай более эффективен: взятие блокировки чтения, когда уже есть хотя бы одна блокировка чтения, или взятие первой блокировки чтения. Я бы предположил первое, так что после того, как все потоки будут запущены путем разблокировки записи, вы можете взять блокировку чтения.
Если ваши потоки не разблокируют чтение-разблокировку, когда они завершены, вам придется что-то сделать разные, или, по крайней мере, испортить внутреннюю реализацию. Вы не хотите уменьшать что-либо по одному счету за раз, пока вы не сможете снять блокировку записи, если накопилось 2 ^ 31 блокировок чтения.
О да, идея caf касается того, что: шлюз - read_lock; read_unlock;