Przemyslaw,
What I was trying to say is that a MT only rtl/hvm can be used with ST code
(like all legacy code) without problems because code that does not use MT
features explicitly will simply be running on thread #1 and will be completely
unaware of being run in a MT capable environment.
This i
On Tue, 04 Dec 2007, Maurilio Longo wrote:
> I think I was not able to explain what I intended to say .)
> with a MT only runtime you have two possibilities:
> - you write MT .prg code (startThread() and the like)
> - you write ST .prg (code ported from clipper)
- create a code which is reentrant
On Tue, 04 Dec 2007, Maurilio Longo wrote:
> this is the answer that I get running your sample:
> 8<-
> Xbase++ (R) Version 1.90 Windows 2000 05.00 Build 02195 Service Pack 4
> 12/04/200
> 7 19.35.29
>
> 1 U U U U
> 2 N U U U
> 3 C C C U
> 1
> 4 C C U U
> 5 U C U U
Przemyslaw,
this is the answer that I get running your sample:
8<-
Xbase++ (R) Version 1.90 Windows 2000 05.00 Build 02195 Service Pack 4
12/04/200
7 19.35.29
1 U U U U
2 N U U U
3 C C C U
1
4 C C U U
5 U C U U
1 U U U U
2 N U U U
3 C C C C
1
4 C C
Przemyslaw Czerpak ha scritto:
>
> On Tue, 04 Dec 2007, Maurilio Longo wrote:
> > Przemyslaw and all involved,
> > If I can say what I think, here it is: I'd like to have just one mode, the
> > MT
> > one, and just one set of extended api, the one we have now. Then, if I don't
> > write .PRG leve
On Tue, 04 Dec 2007, Mike Evans (Gmail) wrote:
> Przemek,
> Maybee this will help you.
> The container API allows access to the internal data structures of Xbase++.
> Each variable in Xbase++ is based internally on a data structure called a
> Container object . Each container object manages the typ
On Tue, 04 Dec 2007, Maurilio Longo wrote:
> Przemyslaw and all involved,
> If I can say what I think, here it is: I'd like to have just one mode, the MT
> one, and just one set of extended api, the one we have now. Then, if I don't
> write .PRG level MT code I simply end up having all my code exec
Przemek,
Maybee this will help you.
The container API allows access to the internal data structures of Xbase++.
Each variable in Xbase++ is based internally on a data structure called a
Container object . Each container object manages the type and the value of a
variable. Access to a container is
Przemyslaw and all involved,
If I can say what I think, here it is: I'd like to have just one mode, the MT
one, and just one set of extended api, the one we have now. Then, if I don't
write .PRG level MT code I simply end up having all my code executed as thread
#1.
This way GC can be on a differ
On Mon, 03 Dec 2007, Mike Evans (Gmail) wrote:
> Przemek,
> I can send you all the manual of xBase++. They have the best manual I've
> ever read and over there you can find a lot of information's As an example :
> SET DELETED on | OFF |
> Scope: thread-local, current work space
Thank you for yo
On Tue, 04 Dec 2007, Mindaugas Kavaliauskas wrote:
> I'm not the MT guru, but just have an idea. In current implementation we
> need access TLS for most of many Item and Extend API functions:
> hb_param(), hb_itemReturn(), hb_par*(), hb_ret*(), etc. The exception is
> some base Item API function
Przemyslaw Czerpak wrote:
which can use it) so there is no simple answer. Without modifications
in core HVM code but changing only HVM stack functions it reduce
the speed of PCODE evaluation over twice in my Linux box.
As I said the most important problem is caused by the fact that
we are using v
Przemyslaw Czerpak wrote:
which can use it) so there is no simple answer. Without modifications
in core HVM code but changing only HVM stack functions it reduce
the speed of PCODE evaluation over twice in my Linux box.
As I said the most important problem is caused by the fact that
we are using v
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Petr Chornyj
Sent: Monday, December 03, 2007 12:13 PM
To: harbour@harbour-project.org
Subject: Re: RE: [Harbour] lib rename proposal (2nd round)
Przemyslaw Czerpak-2 wrote:
>
> On Mon, 03 Dec 2007, Mike Evans (Gmail) wrote:
>
Przemek,
I can send you all the manual of xBase++. They have the best manual I've
ever read and over there you can find a lot of information's As an example :
SET DELETED on | OFF |
Scope: thread-local, current work space
As for variables visibility :
Visibility of variables in different
Przemyslaw Czerpak-2 wrote:
>
> On Mon, 03 Dec 2007, Mike Evans (Gmail) wrote:
> BTW I'm interesting in variable visibility between threads in xbase++.
> I would like to see if we can easy replicate similar behavior. If yes
> then maybe we should not reinvent the wheel because it will be easier
On Mon, 03 Dec 2007, Mike Evans (Gmail) wrote:
Hi Mike,
thanks for informations about xbase++
> Xbase++ Its always MT (Even if you don't start a thread at least the GC is
> running in its own Thread)
Inspector thread which makes GC scan, polls incoming events and serve
background tasks greatly h
> (since for example XBase++ doesn't).
Xbase++ Its always MT (Even if you don't start a thread at least the GC is
running in its own Thread)
>It can be done but please remember that xbase++ is single platform project
>with strictly defined runtime environment so it's much easier to reach
>such ef
On Sun, 02 Dec 2007, Szakáts Viktor wrote:
> So it seems to me that separation mostly goes down to
> performance.
> What amount of performance are we talking about? Which
> kind of functionality is affected the most?
It will be hardly visible in PCODE evaluation and will depend
on cost of accessin
19 matches
Mail list logo
