On Fri, 26 Sep 2008, Randy Portnoff wrote:
Hi Randy,
> Not sure if this was already covered in this thread so I will mention it
> just in case...
> IMO, work areas need to support both per thread and cross thread
> capability, on a per work area basis.
Both are already implemented.
Just simply
Hi all,
Not sure if this was already covered in this thread so I will mention
it just in case...
IMO, work areas need to support both per thread and cross thread
capability, on a per work area basis.
For example, you may have one workarea that needs to be
thread-specific while another can
On Mon, 22 Sep 2008, Szak�ts Viktor wrote:
Hi all interested in PUBLIC like in xBase++
Now user can fully control the memavars inheritance even separately
for public and private vars. IMHO it's very flexible and allows
to use many of existing code using memvars without rewirting it
for MT mode so
Viktor and Przemyslaw,
+1 for a way to be fully xbase++ compatible.
Maurilio.
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman
Hi Przemek,
On 2008.09.22., at 1:14, Przemyslaw Czerpak wrote:
For now, I'd personally vote to make PUBLICs visible for
all threads (otherwise most apps would need to be rewritten
in this respect I guess), and PRIVATEs to the threads that
define them. 'THREAD PUBLIC' could be introduced to crea
On Thu, 18 Sep 2008, Szak�ts Viktor wrote:
Hi all,
> For now, I'd personally vote to make PUBLICs visible for
> all threads (otherwise most apps would need to be rewritten
> in this respect I guess), and PRIVATEs to the threads that
> define them. 'THREAD PUBLIC' could be introduced to create
> P
Hi Przemek,
Many thanks, this is perfectly inline with what I've expected.
Brgds,
Viktor
On 2008.09.18., at 22:25, Przemyslaw Czerpak wrote:
On Thu, 18 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
I also have one:
If a given thread gets a non-handled RTE, or, an internal
error, will the whol
Viktor,
I agree, publics should be public :) between threads with synchronization left
to the user.
This has the advantage to be xbase++ compatible.
I think that on mt issues we should be compatible with xbase++ which is now
the "de facto" standard.
Best regards.
Maurilio.
Szakáts Viktor wro
On Thu, 18 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
> I also have one:
> If a given thread gets a non-handled RTE, or, an internal
> error, will the whole application fail and exit, or just
> the thread where the error occured?
RT errors, begin sequence / break / recover / always statements,
o
Hi Przemek, Mindaugas,
We have few choices. F.e. we can add automatic memvars inheritance
so each child thread will share all parent thread memvars visible
when thread was started as its own PUBLIC variables.
The variables will be shared so you will have to add your own
synchronization code if
Hi folks,
I also have one:
If a given thread gets a non-handled RTE, or, an internal
error, will the whole application fail and exit, or just
the thread where the error occured?
Brgds,
Viktor
On 2008.09.18., at 16:45, Mindaugas Kavaliauskas wrote:
Hi,
1) memvars are local to the thread inc
Przemyslaw,
this is from xbase++ docs (I've attached it), maybe you already did read it.
Anyway I think it could be usefull to be compatible here given that xbase++
has a great user base and has threads since day one.
Best regards.
Maurilio.
PS. I'll try to build latest harbour on OS/2 in the c
On Thu, 18 Sep 2008, Mindaugas Kavaliauskas wrote:
Hi Mindaugas,
> 1) memvars are local to the thread including PUBLICs. I use a few memvars
> to set some global variables/setting, like, comma separator, help file
> name, etc. I do not change it later during program execution. In MT these
> PU
13 matches
Mail list logo
