LIBs e multithread

[JoséQuintas]

Multithread é pouco usada, porque quase ninguém entende isso.
Basicamente é como ter vários EXEs.
Em GTWVG, GTWVT ou equivalente, fica mais visível pra fazer testes e entender um pouco mais, mas TEORICAMENTE dá pra fazer com qualquer LIB.
Multithread é igual EXEs separados, no HARBOUR isso é assim, no Xharbour dizem não funcionar igual.
TANTO FAZ A LIB, não é exclusivo console, apenas acho que console dá uma visão mais prática disso.

Básico:
O que acontece com um programa sem Inkey(0), READ, ou outra coisa ? ele simplesmente não faz nada e fecha.

Código: Selecionar todos

PROCEDURE Main

   SetMode(33,100)
   CLS

   RETURN

Então é necessário um Inkey(0) pra parar o programa na tela, e aguardar uma tecla.

Código: Selecionar todos

PROCEDURE Main

   SetMode(33,100)
   CLS
   Inkey(0)

   RETURN

Também tem algo importante: se NÃO TIVER TELA, o programa vai ficar travado, e precisa ser fechado no gerenciador de tarefas.
OK? Isto acontece com um programa normal, sem multithread, e pode acontecer também com multithread.

Comparem a tela com uma DIALOG, de qualquer lib gui.
Sempre a captura de teclado e mouse vai ser nessa tela, nessa DIALOG.
Sempre precisa existir uma, pra que funcionem mouse e teclado.

[JoséQuintas]

Um programa multithread básico.

A thread principal não pode ser fechada, ela é o ponto de partida do programa, e também a saída.
Aqui eu uso uma thread fantasma, que testa outros processos, mas cada um inventa o que quiser.
O ponto de parada é o teste se tem algo rodando.

Código: Selecionar todos

PROCEDURE Main

   hb_ThreadStart{ || Rotina() } )
   hb_ThreadStart{ || Rotina() } )
   hb_ThreadStart{ || Rotina() } )

   hb_ThreadWaitForAll()

   RETURN

Vai abrir 3 vezes a rotina.
A rotina segue o que foi dito anteriormente, precisa tela - lembrando que tela = tela + teclado + mouse, e um ponto de parada.
Com GTWVG/GTWVT/etc. isso é obtido com gt_Reload()
Com uma LIB GUI seria abrir uma dialog.

Código: Selecionar todos

FUNCTION Rotina()

   hb_gtReload( "WVG" )
   SetMode(33,100)
   CLS
   Inkey(0)

   RETURN Nil

Esse é o básico:
Aqui teremos 3 janelas rodando independentes (podem chamar de DIALOGS)

No caso do harbour, as threads são independentes.
Variáveis não ficam visíveis entre as thread.
Não apenas isso, DBFs também não ficam visíveis, e outras configurações também não.
Talvez até a ERRORSYS também não.

Ok até aqui ?
Aqui vai ver as "DIALOGS", igual qualquer LIB GUI.

Importante destacar que existem as INIT PROCEDUREs e INIT FUNCTIONs, executadas automaticamente ao iniciar um programa.
Isso só acontece na thread principal, em multithread, nas threads seguintes não.
Lembram ? Multithread é igual EXE separado... essas INITs são pra executar no início do EXE, e não em cada thread, então os "outros EXEs" ficam sem.

[JoséQuintas]

E LIB GRÁFICA ?

As LIBs gráticas tem INIT PROCEDURE ou INIT FUNCTION.
Elas são executadas automaticamente, mas só na primeira thread.
Digamos que seria parecido com o que uso em GTWVG, é o ponto de parada de tudo, pro resto funcionar.
Se não me engano, em HWGUI é Init(), em MINIGUI é _Init()

Considerem o mesmo MAIN que coloquei antes.
Testado, só usei com GTWVG, mas deve funcionar com as demais, WVT e equivalente LINUX.
O módulo pra multithread ficaria assim:

Código: Selecionar todos

FUNCTION Rotina()

   hb_gtReload( "WVG" )
   Init() // init da LIB gráfica
    .....
   RETURN Nil

O init da lib faz o papel equivalente de introduzir um Inkey(0), e algo mais que a LIB GUI precise.
O hb_gtReload( "WVG" ) faz o papel de dar a rotina aonde vai ser aplicado o Inkey(0), a rotina a ser congelada.
HWGUI vai ter o que precisa pra funcionar, MINIGUI vai ter o que precisa pra funcionar.

Não sei fivewin, sem fontes não há o que fazer.

Qual a vantagem de multithread ?
Vai trabalhar com várias janelas, várias DIALOGs ? cada uma fazendo o que quiser?
Então... multithread, cada DIALOG usa o que quiser e faz o que quiser.
SEM GAMBIARRAS pra trabalhar com DBF, que é a base padrão do harbour.

Abre uma DIALOG
Essa dialog abre arquivos
No final, CLOSE DATABASES
Uma coisa tão simples, continua simples em multithread.

Dá pra fazer isso com GTWVG, HWGUI, MINIGUI. e qualquer LIB que aceite multithread.

FIVEWIN está fora disso, pelo menos pelo que sei, e por enquanto.
Nele só resta inventar infinitos ALIAS, controlar o que foi aberto, e fechar no final.
Ou usar classes, ou outra gambiarra que modifique o comportamento normal do harbour.
Devem usar isso com HWGUI e MINIGUI também, sendo que não precisaria.

[JoséQuintas]

Que outros detalhes poderiam existir em cada LIB pra multithread ?

Em MINIGUI existe uma variável linguição com tudo: _HMGSYSDATA ou algo assim.
É uma variável PUBLIC.
Em multithread, com a chamada de INIT(), ela é criada em cada thread, pronto, resolvido.

Em HWGUI precisou algo mais.
Tem lá nas classes CLASSVAR aDialogs (ou algo assim, não importa o nome agora)
Fiz a alteração e deixei como parâmetro de compilação.
Alterei pra THREAD STATIC aDialogs
A diferença é que sem alteração a lista é única, com alteração a lista é pra cada thread.
Sem a alteração, no uso normal, é obrigado a fechar as dialogs na ordem em que foram criadas.
Com a alteração, cada thread fica livre, independente, pode fechar na ordem que quiser.
É.... porque essa lista é usada como referência na hora de fechar.

Basicamente é isso: as LIBs GUI tem a lista de janelas, a lista pode ou não ficar visível entre threads, o ideal é cada thread enxergar o que é seu, pra ser totalmente independente.

Recapitulando:
- a LIB GUI começa travando o processo inicial, dar um processo em GTWVG ou outro, fornece o que vai ser travado
- a LIB GUI tem seu controle de janelas, se for independente por thread dá infinitas possibilidades

E o que mais?
Se a LIB fica restrita à thread.... podemos usar quantas LIBs quisermos.
Na prática isso de misturar LIBs é bom para a fase de migração e testes.
Tem lá seu aplicativo, seja o que for, GTWVG, HWGUI, MINIGUI, etc. pode trocar uma tela por vez.

Lógico, nem tudo é alegria....
FIVEWIN sem opção, fontes fechados não há o que mexer
MINIGUI tem seus bugs, MAIN WINDOW OFF seria extremamente importante, mas na HMG Extended não foi implementado em totalidade, problemas com foco que normalmente já acontecem, podem piorar.

Mas se usuários pedirem o recurso, podem acabar ajustando o que precisa.
Como ninguém usa, tanto faz, pra que facilitar o que ninguém pede pra facilitar ?

Faltou HWGUI: pra HWGUI tanto faz usar DIALOG ou WINDOW. É usar só DIALOG, não sei porque WINDOW dá erro.

Outra coisa importante:
DIALOG NÃO MODAL
Em multithread, a primeira DIALOG SEMPRE tem que ser MODAL.
Lembram ? precisa do ponto de parada. MODAL é o ponto de parada. Não vai bloquear janela anterior, porque não existe janela anterior.

O teste inicial com GTWVG dá uma idéia disso, do ponto de parada "na DIALOG", na GTWVG fica visível porque é o Inkey(0) visível no fonte.
Em LIB GUI isso é invisível, a própria LIB GUI trata disso.

[JoséQuintas]

Lembrando também:

Quando se fala de DBF, isso pode incluir hbnetio, lettodb, SQLRDD, SQLMIX, etc.
Todos trabalham no estilo DBF.
Mas nem me perguntem, nunca usei nenhum deles.
É apenas suposição.

Não entenderam a vantagem de multithread?

Código: Selecionar todos

// uma DIALOG
use clientes new
use fornecedores new
...
close databases

Pra multithread, isso acima é normal, a dialog vai trabalhar tranquilamente com seus DBFs, não importa mais nada.
Pode até abrir a mesma dialog milhares de vezes, que cada uma vai funcionar normalmente, sem interferir na outra.
Sem gambiarras, sem problema.

Quer mais ?
Se quiser, pode usar também o QUIT.
Só a thread/dialog vai ser fechada, e só o que faz parte dela.
Lembram ? igual EXE separado.... pra que ficar controlando dbf pra abrir e fechar, controlar índice, posição, etc. ?

Sua LIB não tem isso ? precisa ficar abrindo arquivos usando ALIAS diferentes ? e controlar pra fechar no final ?
Precisa criar rotinas pra alias diferentes em cada dialog ?
Fazer o que....
Tem lib que não evolui.
E deve inventar várias desculpas sobre isso, talvez até culpar o harbour.