cache_(un)set_active - вопрос по нему

[ORLADOK]

Здравствуйте, я ранее не прибегал к насилию функций, которых не знаю.
Однако, наступил такой день, когда пришла пора идти в путешествие по каждой функции, подключаемых мной библиотек.

Особо описаний этой функции я не совсем понял, потому я задам вопрос тут, на форуме хороший людей.

Недавно я спрашивал как сделать лучше в одном вопросе и решение мне предоставили. Но автор (надеюсь, что этой темой его не оскорблю), к сожалению, не дал нужного мне ответа на следующий вопрос (цитата моего сообщения):

Разве стоит использовать кеш в авторизации?
Не будет при 2 игроках такой каши:

cache_set_active(playerid = 0);
... // получение данных для playerid = 0
cache_set_active(playerid = 1);
... // получение данных для playerid = 1
... // конец получения данных для playerid = 1
cache_unset_active();
... // конец получения данных для playerid = 0
cache_unset_active();
?

Вероятность, конечно, мала, но как я понял из разных статей (wiki/pro-pawn) он создает глобальный поток, нет?

Допустим, здесь еще понятно почему это лучше использовать (дабы не прибегать к насилию памяти скрипта): Спасибо DeimoS'у за пример (клык!) (http://pro-pawn.ru/showthread.php?16339-%D0%9F%D0%BE%D0%BC%D0%BE%D0%B3%D0%B8%D1%82%D0%B5-%D1%81-%D0%BB%D0%BE%D0%B3%D0%B0%D0%BC%D0%B8&p=91929&viewfull=1#post91929)

Но правда ли не будет путаницы? Кажется, в прошлой версии (в той, что поток был не глобальным) было с этим несколько легче?

Спасибо.

[DeimoS]

Эмм, ты немного не понимаешь того, что означает "многопоточность" в MySQL-плагине :) Когда речь идёт про многопоточность - это не значит, что вообще весь код, связанный с MySQL начнёт обрабатываться в отдельном потоке. Нет. В отдельном потоке будут обрабатываться лишь запросы, которые отправлены через специальные функции (mysql_tquery и mysql_pquery). Точнее, плагин просто не будет останавливать весь поток сервера, ожидая ответ от базы данных, а просто сам дождётся этого ответа и "вклинится" в поток, как только этот ответ обработает.

Соответственно, твой пример будет работать так и никак иначе:

cache_set_active(playerid = 0);
... // получение данных для playerid = 0
... // конец получения данных для playerid = 0
cache_unset_active();

cache_set_active(playerid = 1);
... // получение данных для playerid = 1
... // конец получения данных для playerid = 1
cache_unset_active();
Так как обработкой этого кода будет заниматься уже именно сервер со своим одним общим потоком для всего.

[ORLADOK]

Спасибо, ты пояснил мне про поточность. Буду знать что это))

Однако вопрос остался: стоит ли использовать каши (cache) в авторизации?)

[Меня не изменить с моим картавием. Люблю дурачиться]

[DeimoS]

Кэши, а не каши :)

Ну да, почему бы и не использовать? Ты будешь посылать всего 1 запрос и далее работать напрямую с данными, а не терзать постоянно БД.
Только не забывай удалять вовремя кэш, ибо иначе быстро словишь краш от переполнения памяти, если кэш, например, будет хранится после выхода игрока с сервера

[ORLADOK]

Про удаление я помню (как только начал боле-менее знакомиться с этой функцией, то сразу уяснил). И во всех ли тогда случаях он выигрывает?

[DeimoS]

Эмм, в смысле? Везде, где на то позволяет ситуация. Ты ведь просто указываешь плагину хранить результаты запроса в памяти у себя, а не удалять их после того, как паблик, в котором был вызван запрос, закончит свою обработку. И там, где возможно работать с заранее сохранёнными данными, логично работать именно с ними, а не получать одни и те же данные по 100 раз.

[ORLADOK]

Ладно, я помолчу :))
В целом, вопрос закрыт =)