HB_IdleWaitNoCPU() tem ela no HARBOUR?

[ANDRIL]

Procurei através do hbmk2 e não encontrei, sabem se existe outra semelhante ela é do xHarbour, mesmo colocando no projeto xhb.lib não acha.
Acho que esta função pode resolver meu problema no screensaver que criei, um simples exibidor de JPG.

O problema é que quando é executado o exibidor ou qualquer outra função, a CPU pula de 1 a 50 ciclos, deixando o a máquina lenta.

Segundo o manual xHarbour a função tem o seguinte propósito: (foi traduzido via google)

Por padrão, um estado de espera inativa é realizada por uma função interna que monitora um intervalo de tempo. Isto requer recursos da CPU. Quando <l'Mode> está definido para. T. (True), um estado de espera é supervisionado pelo sistema operacional, que não requer recursos de CPU extra.

Até+

[Itamar M. Lins Jr.]

Ola!
Cadê o código ?

Saudações,
Itamar M. Lins Jr.

[Kapiaba]

Ou, além do pedido pelo Sr. Itamar, inicie o programa(módulo) com:

Código: Selecionar todos

   HB_GCALL( .F. ) // Limpa a memória, somente se tiver lixo(basura).

E, ao fechar o seu programa principal, não esqueça de limpar geral com:

Código: Selecionar todos

   CEAR MEMORY

Veja se não é isso:

https://pctoledo.org/forum/viewto ... 47&t=10744

http://www.creasolgroup.com/xOraclipLan ... _f.en.html

Abs.

[Itamar M. Lins Jr.]

Ola!

HB_GCALL( .F. ) // Limpa a memória, somente se tiver lixo(basura).

Isso é para quem usa xHarbour.

CEAR MEMORY

Creio que quis escrever, Clear Memory, e também não precisa disso. Ao fechar um programa toda a memória é limpa, a não ser que exista os vazamentos (memory leaks)...


Saudações,
Itamar M. Lins Jr.

[lugab]

Boa tarde...

Amigos, eu uso XHarbour e talvez possa me beneficiar dessas dicas...

Então, o que devo usar pra dar uma acelerada no desempenho: ?

Código: Selecionar todos

 HB_GCALL( .F. ) // Limpa a memória, somente se tiver lixo(basura). 

ou

Código: Selecionar todos

 HB_IdleWaitNoCPU() 

...ou posso usar os dois no mesmo sistema, caso eles atuem de forma diferente ?

[Itamar M. Lins Jr.]

Esses comandos não aceleram nada, são apenas gambiarras para corrigir os bugs do GC do xHarbour. No harbour os conhecidos foram corrigidos...Inclusive das bibliotecas de terceiros GT_WVW por exemplo.

http://www.marinas-gui.org/projects/har ... lector.htm

### OBJECT DESTRUCTORS ###
================================
Both Harbour and xHarbour support object destructors and both
compilers uses reference counters and garbage collector to
execute destructors. Anyhow the low level implementation is
different in the two compilers. In Harbour HVM is reentrant safe
so the implementation of destructors is much simpler. It also
keeps full control about reference counters and detects user
code errors bound with complex items in .prg and C code what
greatly helps to detect problems in user code or 3-rd party
libraries and gives protection against internal HVM memory
corruption. In the last years it also helped to located few
very hard to exploit bugs in core code.

In xHarbour there is some basic protection but it was never
fully functional. Sometimes it may cause that internal error
message is generated but in most of cases internal HVM memory
is silently corrupted. A good example which illustrates what
may happen is in Harbour source repository in harbour/tests/destruct.prg
This code can be compiled and executed by Harbour and xHarbour.
But only Harbour version detects user errors generating RTE
and is necessary in all cases to keep internal memory cleaned
protecting against corruption. The xHarbour version behavior
is random because this .prg code corrupts internal HVM memory.
It's possible that it will be executed without any visible
errors or it will generate GPF or internal error. But in all
cases it can be well seen using tools like valgrind or CodeGuard
that it corrupts internal memory so the results are unpredictable.
I.e. this is part of valgrind log generated during execution
of above destruct.prg compiled by xHarbour:

==22709== Invalid read of size 2
==22709== at 0x426E235: hb_gcItemRef (garbage.c:646)
==22709== by 0x425EDE5: hb_memvarsIsMemvarRef (memvars.c:2396)
==22709== by 0x426E674: hb_gcCollectAll (garbage.c:847)
==22709== by 0x426E899: HB_FUN_HB_GCALL (garbage.c:1179)
==22709== Address 0x485b096 is 22 bytes inside a block of size 56 free'd
==22709== at 0x4023B7A: free ()
==22709== by 0x42837A9: hb_arrayReleaseBase (arrays.c:1588)
==22709== by 0x428381A: hb_arrayRelease (arrays.c:1602)
==22709== by 0x4256B94: hb_itemClear (fastitem.c:248)
[...]
==22709== Invalid write of size 2
==22709== at 0x426E4C6: hb_gcItemRef (garbage.c:652)
==22709== by 0x425EDE5: hb_memvarsIsMemvarRef (memvars.c:2396)
==22709== by 0x426E674: hb_gcCollectAll (garbage.c:847)
==22709== by 0x426E899: HB_FUN_HB_GCALL (garbage.c:1179)
==22709== Address 0x485b096 is 22 bytes inside a block of size 56 free'd
==22709== at 0x4023B7A: free ()
==22709== by 0x42837A9: hb_arrayReleaseBase (arrays.c:1588)
==22709== by 0x428381A: hb_arrayRelease (arrays.c:1602)
==22709== by 0x4256B94: hb_itemClear (fastitem.c:248)
[...]
==22709== Invalid read of size 4
==22709== at 0x426E223: hb_gcItemRef (garbage.c:603)
==22709== by 0x425EDE5: hb_memvarsIsMemvarRef (memvars.c:2396)
==22709== by 0x426E674: hb_gcCollectAll (garbage.c:847)
==22709== by 0x426E899: HB_FUN_HB_GCALL (garbage.c:1179)
==22709== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==22709== Process terminating with default action of signal 11 (SIGSEGV)
==22709== Access not within mapped region at address 0x0

Harbour executes above code cleanly without any errors:

==28376== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 1)
==28376== malloc/free: in use at exit: 0 bytes in 0 blocks.
==28376== malloc/free: 6,164 allocs, 6,164 frees, 10,323,064 bytes allocated.
==28376== All heap blocks were freed -- no leaks are possible.

Missing protection and error detection is not only problem for programmers.
It also causes that in xHarbour core code few bad bugs have not been fixed
so far though they exist for years. It also extremely time consuming problem
for core developers when users or 3-rd party developers reports problems with
some memory corruption and it's necessary to locate the reason.
I remember how much time I lost for such things working on xHarbour
in the past so later when I moved to Harbour it was one of the main goal
for me to resolve the problem.

In xHarbour there is disabled code which was designed to detect such
problems and it can be enabled by setting HB_ARRAY_USE_COUNTER_OFF macro
but it causes horrible runtime overhead and was never finished to be ready
as production extension. Such solution seems to be dummy way so I do not
believe that it will be ever finished.

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

https://pctoledo.org/forum/viewto ... f=4&t=6521
Aqui outro problema de GC conhecido que tinha/tem no xHarbour ?, que não tem no Harbour.

Saudações,
Itamar M. Lins Jr.

[lugab]

Certo, Itamar...

De qualquer forma, parece haver serventia pro Xharbour, de N em N minutos, pra dar uma limpada na memória