multithreading - Synchronize () DLL freezes without errors and crashes -

pascal lazarus.

first, thank in advance help, , apologize long text found necessary explain; , english bad - i'm using google translator.

i built modular program consisting of several programs (exe), , in cases these modules in dll. there 6 modules.

all of these modules used functions of thread. thread not use visual components, analyze huge files (> 1gb).

to improve efficiency , organization, extract code relating file analysis, used each of modules. facilitates updating , find error.

the threads worked before, no code change, except necessary adapt them dll project.

now, when run procedures of thread, functions except synchronize () method, freezes without making errors or lock main program.

the synchronize () method used because threads created entirely within dll. therefore, main program called procedure dll, creates , runs thread, without intervention main program.

for procedure passed several parameters, 1 of them type "pointer procedure" ^procedure, using event, fired thread through synchronize () periodically, ensuring during performance, lasted more 1 hour in sometimes, if track progress, see errors errors among others.

i searched on google did not find information except saying possibly synchronize () method waiting main process not responding unknown reasons.

note: main program , window not lock or freeze; thread not call / run procedure provided synchronize (); confirmed it!

added

nota2: want avoid use postmessage () or similar, because forces me include lcl, makes dll file current 300k 2mb (in release mode). apart there reports operation not expected.

i appreciate help.

original language (pt_br):

synchronize () em dll congela, sem erros e travamentos. pascal in lazarus. primeiramente, agradeço de antemão ajuda, e peço desculpa pelo longo texto que achei necessário para explicar; e o péssimo inglês - estou usando google translator.

eu construí um programa modular, composto de vários programas (exe) e, em alguns casos estes módulos também estão em dll. existem cerca de 6 módulos.

todos estes módulos utilizavam funções de uma thread. este thread não usa componentes visuais, o que ela faz é basicamente analisar arquivos gigantescos (>1gb).

para melhorar eficiência e organização, extraí todo o código relativo à esta análise de arquivo, que é usado por cada um dos módulos. isso facilita atualização e encontrar erro.

os threads funcionavam normalmente antes, não houve alteração código, exceto o necessário para adaptá-los ao projeto dll.

agora, quando executo os procedimentos da thread, tudo funciona normalmente, exceto o método synchronize (), que congela sem emitir erros ou travar o programa principal.

o método synchronize () é usado porque os threads são criados inteiramente dentro da dll. por isso, no programa principal é chamado um procedimento da dll que cria e executa o thread, sem qualquer intervenção programa principal. para este procedimento são passados vários parâmetro, um dele é um tipo de ponteiro para procedure, quem é usando como um evento, disparado pelo thread através synchronize () periodicamente, garantido que durante execução, que dura mais de 1 hora na maioria das vezes, se acompanhe o progresso, veja erros os erros dentre outros.

procurei no google, porém não encontrei informação, exceto alguém falando que possivelmente o método synchronize () está aguardando o processo principal que não está respondendo por motivos desconhecidos.

nota: o programa principal e janela não travam nem congelam, apenas o thread, que nem mesmo executa procedure fornecida em synchronize (); verifiquei isso!

added

nota2: want avoid use postmessage () or similar, because forces me include lcl, makes dll file current 300k 2mb (in release mode). apart there reports operation not expected.

agradeço ajuda.

that because have 2 complete instances of (rtl,lcl etc). 1 set in dll, 1 set in exe. both code , data.

you calling synchronize of dll, schedules lcl loop in dll nothing, since work done in exe.

this hard fix, need packages this. partially because thread involvement further complicate because of threadvariables (thread local storage) set potentially differently dll , exe threads.

for 1 needs packages in initial stages , solves having 1 copy of everything. see link deeper treatise.