прокси в многопоточной программе

[Steam~]

Пишу многопоточный чекер с проксями, многопоточность написана, работает как часы, но вот когда подключаешь прокси не валидные акки в валидный записывает(и на оборот), до конца по всему списку аккаунтов не доходит(при большом кол-во). Что не так? и как исправить..
Вот код потока
procedure TNewThread.Execute;
var CurAcc:integer;
data:TstringList;
[Ссылки могут видеть только зарегистрированные и активированные пользователи]
ps, pp,resultt:string;
begin
while Work do
begin
CS.Enter;
inc(tp);
Inc(Acc);
if Acc<Accounts.Count then CurAcc:=Acc else Work:=false;

if tp=Proxys.Count-1 then tp:=0;

CS.Leave;

if Work then
begin
FAcc:= Copy(Accounts[CurAcc],1,Pos(';',Accounts[CurAcc])-1);
FPas:= Copy(Accounts[CurAcc],Pos(';',Accounts[CurAcc])+1,Length(Accounts[CurAcc]));

ps:=Copy(Proxys[tp], 1, Pos(':',Proxys[tp])-1); //Копируем адрес
pp:=Copy(Proxys[tp], Pos(':', Proxys[tp])+1, Length(Proxys[tp])); //Копируем порт

http := Tid[Ссылки могут видеть только зарегистрированные и активированные пользователи]
Data := TStringlist.Create();
try
data.add('loginForm_default_username='+FAcc);
data.add('loginForm_default_password='+FPas);
[Ссылки могут видеть только зарегистрированные и активированные пользователи]
[Ссылки могут видеть только зарегистрированные и активированные пользователи]
[Ссылки могут видеть только зарегистрированные и активированные пользователи](pp);
try
resultt:=[Ссылки могут видеть только зарегистрированные и активированные пользователи]('[Ссылки могут видеть только зарегистрированные и активированные пользователи]',data);
except
rez:=0;
end;
if pos('loginErrorMessage',resultt)<>0 then rez:=-1
else
if pos('[Ссылки могут видеть только зарегистрированные и активированные пользователи]',resultt)<>0 then rez:=1
else
rez:=0;


Application.ProcessMessages;
[Ссылки могут видеть только зарегистрированные и активированные пользователи]
data.Free;
finally
end;
Synchronize(Sync);
end;
end;

dec(Thread);
if Thread=0 then ShowMessage('OK');
end;

на каждый новый цикл берется новая прокся, при рез=0 аккаунт записывается в конец списка для повторной проверки

[Steam~]

что прям совсем никто не знает в чем трабл?

[J-Fobos]

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

[VeTaL_UA]

многопоточность написана, работает как часы
Всегда меня такие фразы настораживали /nyan

[Steam~]

Подозреваю, что проблема в прямом использовании переменных главного потока в дочерним потоке.
все переменные главного потока находятся в крит.секциях

[Dinmaite]

Я вообще не вижу здесь половины кода. Критических секций не вижу. Записи в файл не вижу. Это "Application.ProcessMessages;" меня страшно настораживает.

[iNugno]

Это "Application.ProcessMessages;" меня страшно настораживает.

-Реакция на дальнейшую строку, а потом выполнение.
Пример:

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

while not eof(список) do
begin
...
end;


валидность - убери проверку на обратное, если при удачном входе у нас выскочило "то-то", тогда мы "это" добавляем в другой список\массив, что угодно.

Как выглядит:

1)Берем себе прокси
2)Берем логин
3)Берем пароль
4)Проверяем логин\пасс
5)Да - пишем куда-то.

[Dinmaite]

-Реакция на дальнейшую строку, а потом выполнение.
Не говори этих глупостей. Эта строка в отдельном потоке написана.

А то что ты предлагаешь больно похоже на однопоточное приложение.

[iNugno]

Не говори этих глупостей. Эта строка в отдельном потоке написана.

А то что ты предлагаешь больно похоже на однопоточное приложение.

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

А насчет глупостей - ок, докажем это:
Справка:
Interrupts the execution of an application so that it can process the message queue.
+
Call ProcessMessages to permit the application to process messages that are currently in the message queue. ProcessMessages cycles the Windows message loop until it is empty, and then returns control to the application.

[VeTaL_UA]

iNugno, ты говоришь бред. ProcessMessages нужно вызывать, если цикл работает в основном потоке, чтобы вернуть приложению контроль. Нафига его в потоке вызывать? Где логика?

[iNugno]

Нафига его в потоке вызывать? Где логика?
Т.к. я не вызывал сей месседж, поэтому не скажу. (Я его использовал в таймере, пример выше)
А то, что я говорю бред - читаем справку, понимаем, что все, что я написал выше - полнейшая правда. Дин не знает, что такое ProcessMessages, я ему показал. А теперь, как оказалось, я остаюсь незнайкой. Соглашусь, что немного не верно "-Реакция на дальнейшую строку, а потом выполнение" - но суть так же.

[VeTaL_UA]

Я его использовал в таймере, пример выше
Красавец!!! Только нафига он в таймере? :d
Дин не знает, что такое ProcessMessages, я ему показал.
:d :d :d У дина опыта в раз 10 больше моего, а про тебя я молчу :D

Дальнейший текст даже комментировать не хочу :D

[Dinmaite]

Т.к. я не вызывал сей месседж, поэтому не скажу. (Я его использовал в таймере, пример выше)
А то, что я говорю бред - читаем справку, понимаем, что все, что я написал выше - полнейшая правда. Дин не знает, что такое ProcessMessages, я ему показал. А теперь, как оказалось, я остаюсь незнайкой. Соглашусь, что немного не верно "-Реакция на дальнейшую строку, а потом выполнение" - но суть так же.


Ты читаешь справку но не понимаешь о чем пишешь. То что ты написал "полнейшая правда" лишь в случае объявления application.processmessage в основном потоке приложения (в потоке, в котором обрабатываются все события формы). Дин прекрасно знает что это такое, и указал тебе на это еще несколькими постами выше, не нужно пытаться выставить меня неучем.

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