Não vamos deixar o assunto morrer...
Como poderÃamos iniciar....
É apenas alguém ou alguns pra dar continuidade no suporte, quem não quiser é só não participar.
Paulo

Moderador: Moderadores
Como poderÃamos iniciar....
É apenas alguém ou alguns pra dar continuidade no suporte, quem não quiser é só não participar.
ele estranhou aparentemente terem removido a multithread da HWGUI que ele havia acrescentado na 2.17
### MULTI THREAD SUPPORT ###
==================================
Both compilers support multi thread programming and in both
compilers to use threads it's necessary to use MT version of VM.
In Harbour it's only single HVM library because in both versions
(ST and MT) Harbour VM gives exactly the same public API so it's
not necessary to create separate versions of any other libraries
or create different .prg code for MT and ST modes.
The separate ST version of VM can be linked with applications
which do not create any threads to improve the performance because
it's a little bit faster then MT VM. The speed difference can be
compared using speedtst.prg (results below). For other platforms/C
compilers it may be a little bit bigger or smaller anyhow it's
not very huge and Harbour in MT mode is still much faster then
xHarbour in ST mode.
In summary MT mode in xHarbour looks like a work in progress, started few
years ago and never finished. Instead some other core code modifications
in last years systematically introduced new non MT safe code and in few
cases even broke existing MT extensions.
I cannot say if xHarbour developers plan to make something with it.
Now I cannot even describe it well because looking at the xHarbour source
I do not know what is intentional decision, what is a bug in implementation
and what is unfinished code, i.e. such code:
JoinThread( StartThread( @func() ) )
in xHarbour has race condition and can generate RT error if new thread
finished before join operation begin. For me it's bad design decision
or fatal side effect of wrong implementation but I do not plan to guess.
This is very trivial example and I see in core code much more serious
and more complicated problems I had to resolve in Harbour which are not
touched at all in xHarbour.
Na época do Basso, existiam BATs diferentes pra compilar com e sem multithread.
pauloa1 escreveu:Não vamos deixar o assunto morrer...
Como poderÃamos iniciar....
É apenas alguém ou alguns pra dar continuidade no suporte, quem não quiser é só não participar.
Paulo
Infelizmente por aqui, não vai dar sequencia, tem gente que faz questão de bagunçar o correto
asimoes escreveu:Se for para ir na linha do xharbour, to fora!
prefiro ficar na minha versão 2.17 modificada por mim para meu uso.
JoséQuintas escreveu:Espero que isso não tenha sido considerado isso como bagunçar o coreto, porque pode demonstrar que um caminho já definido é XHarbour apenas.
E nesse caso, o Culik seria o mais indicado, e não o Basso.
Usuários vendo este fórum: Nenhum usuário registrado online e 3 visitantes