Hi,
Przemyslaw Czerpak wrote:
You can simply create separate thread which will execute your tasks.
F.e. sth like:
static function hb_backgroundThread()
local n, nTime
while !s_lStop
hb_mutexLock( s_mutex )
nTime := s_nLastTime
...
thanks for a great samp
Przemyslaw Czerpak wrote:
Fine but I suggest to create separate function to extract number of
seconds from some starting day, f.e.:
HB_FUNC( HB_MILLISEC )
{
hb_retnin( hb_dateMilliSeconds() );
}
and use it instead of seconds().
Hi,
I've looked to the source and can commit new
Hi,
Fine but I suggest to create separate function to extract number of
seconds from some starting day, f.e.:
HB_FUNC( HB_MILLISEC )
{
hb_retnin( hb_dateMilliSeconds() );
}
and use it instead of seconds().
Yes, it would be great.
In harbour/tests/mt/ you have simple demonst
Przemyslaw Czerpak wrote:
I have few days delay receiving messages from harbour-devel list.
Sometime I receive them immediately sometimes after two weeks.
Now I'm answering for 5-th message coping their bodies from
http://lists.harbour-project.org/pipermail/harbour/
Hi,
the same for me. Somet
Hi Przemek,
Il 09/12/2008 16.33, Przemyslaw Czerpak ha scritto:
It seems to me that SET() values are read before starting Threads, then
they are separated and not shared between threads.
So if I define some SETs before starting threads it works, but once they
are started all changes are igno
Hi Francesco,
> sorry for previous poor message, but it was too late and I was tired.
> Now I have done a self contained sample to show what I mean.
There is nothing to be sorry. It was very good question. Just simply
I have few days delay receiving messages from harbour-devel list.
Sometime I re
Hi Mindaugas,
> thanks for a great sample code. It is great because it makes me to ask a
> few questions, and to understand the details of process sync.
>
> There are things I do not like in this sample, and I'd like to make it
> more perfect. The first thing I want to optimize is loop contain
Hi Przemek,
sorry for previous poor message, but it was too late and I was tired.
Now I have done a self contained sample to show what I mean.
It seems to me that SET() values are read before starting Threads, then
they are separated and not shared between threads.
So if I define some SETs be
Hi Przemek,
Il 07/12/2008 18.07, Przemyslaw Czerpak ha scritto:
I haven't tested above code. I've just written it as an example.
Are SET() functions Thread shared ?
I'm trying to implement your sample for background tasks, but is seems
to me that SET are not working between threads.
In my r
Hi Przemek,
Il 07/12/2008 18.07, Przemyslaw Czerpak ha scritto:
In UDP packets can be lost by definition and it's programmer job
to detect it and repeat messages if necessary.
Here MT mode can help only indirectly by reducing some time conditions
but it does not eliminate the problem.
Yes, I
On Fri, 05 Dec 2008, Francesco Saverio Giudice wrote:
Hi Francesco,
> In meanwhile I have tried and my code seems to work correctly: speed is
> impressive and in MT mode I'm not loosing UDP packets as I did in ST
In UDP packets can be lost by definition and it's programmer job
to detect it and
Hi Przemek,
Il 05/12/2008 11.37, Przemyslaw Czerpak ha scritto:
No, I'm not familiar with hblog* code. Anyhow if it operates on
separated resources then is should be safe. But to say sth more
I will have to look at this code.
It will be good. Actually it seems to me correct, apart from OS
f
On Thu, 04 Dec 2008, Francesco Saverio Giudice wrote:
Hi Francesco,
> I'm working with Inet*() functions and hblog.
> In my repository I have updated Inet with RAW connections, actually UDP raw
> connections, and packets manipulation (I need to spoof IP for a specific
> application).
> All work
Hi Przemek,
I'm working with Inet*() functions and hblog.
In my repository I have updated Inet with RAW connections, actually UDP
raw connections, and packets manipulation (I need to spoof IP for a
specific application).
All works well in non MT env.
Now I'm trying to test this app in MT envir
14 matches
Mail list logo
