Op 2010-07-27 07:32, Martin het geskryf:
>
> 1) find a char , that is not possible in a path on any system
That's going to be rather hard under Linux. Linux (ext2, ext3, ext4, JFS,
XFS etc) supports all bytes except for NULL and /. And yes, even none
visual chars can be used - in their escaped fo
Op 2010-07-27 00:13, Marc Weustink het geskryf:
>
> Florian asked about rejected *compiler* patches, not RTL.
And I spoke about code contribution to the "FPC project" - as a whole.
G.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lis
On 27/07/2010 03:30, Adem wrote:
On 2010-07-27 5:06 AM, Martin wrote:
You would make a notE of that in a cfg file --either a global one,
or per project.
You mean as in a namespace to path translation?
so I write in my cfg
C:\laz_svn\ = C:\lazarus
?
Can we please think out of the box of how yo
On 27/07/2010 04:23, Marco van de Voort wrote:
In our previous episode, Martin said:
Extend it do declare an alias for the path (which then is your namespace
-Fu=SynEdit::/path/to/symedit
: is a legal char on Unix:
True, just abn example...
2 possibilities:
1) find a char , th
The first version of the OO rewrite branch is ready for alpha testing :-)
Now I need assistance in testing and profiling it. Can somebody do that,
or give me instructions how to do that myself?
The current version still uses global variables, which shall be moved
into objects in the next round
In our previous episode, Martin said:
>
> Extend it do declare an alias for the path (which then is your namespace
>
> -Fu=SynEdit::/path/to/symedit
: is a legal char on Unix:
[Turtle] mkdir ::
[Turtle] ls -lad ::
drwxr-xr-x 2 marcov users 4096 Jul 27 05:23 ::
[Turtle]
___
On 2010-07-27 5:06 AM, Martin wrote:
You would make a notE of that in a cfg file --either a global one, or
per project.
You mean as in a namespace to path translation?
so I write in my cfg
C:\laz_svn\ = C:\lazarus
?
Can we please think out of the box of how you would fit that in the cfg
file
On 27/07/2010 02:48, Adem wrote:
On 2010-07-27 4:14 AM, Martin wrote:
And, it seem you did not read the rest of my post (including the
first one with this subject line) :)
Yes.
I am with Graeme on this one, as in I do not see what you may have
written, that solved the above
To be sure:
Correction:
You would make a NOTE of that in a cfg file --either a global one, or
per project.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 2010-07-27 4:14 AM, Martin wrote:
And, it seem you did not read the rest of my post (including the
first one with this subject line) :)
Yes.
I am with Graeme on this one, as in I do not see what you may have
written, that solved the above
To be sure: this mail ?:
http://lists.freep
On 27/07/2010 01:48, Adem wrote:
On 2010-07-27 1:08 AM, Graeme Geldenhuys wrote:
2010/7/27 Adem :
I wouldn't have much of an issue with something like
uses
zip IN '/units/my/zip.pas' AS myzip;
zip IN '/units/lib/zip/zip.pas' AS ziplib;
And if you have multiple developers working on the s
On 2010-07-27 1:08 AM, Graeme Geldenhuys wrote:
2010/7/27 Adem :
I wouldn't have much of an issue with something like
uses
zip IN '/units/my/zip.pas' AS myzip;
zip IN '/units/lib/zip/zip.pas' AS ziplib;
And if you have multiple developers working on the same project and
their source code
On 26/07/2010 23:08, Graeme Geldenhuys wrote:
2010/7/27 Adem :
I wouldn't have much of an issue with something like
uses
zip IN '/units/my/zip.pas' AS myzip;
zip IN '/units/lib/zip/zip.pas' AS ziplib;
And if you have multiple developers working on the same project and
their sour
Graeme Geldenhuys wrote:
On 26 July 2010 22:57, Florian Klämpfl wrote:
What makes you think so? Which compiler patches did we reject so far?
Lets take some examples in the last few months alone. I had code for
the RTL. Iterators come to mind - denied. Then there was a patch for a
more cross-p
2010/7/27 Adem :
> I wouldn't have much of an issue with something like
>
> uses
> zip IN '/units/my/zip.pas' AS myzip;
> zip IN '/units/lib/zip/zip.pas' AS ziplib;
And if you have multiple developers working on the same project and
their source code directory hierarchy is not exactly the same
On 2010-07-26 11:31 PM, Marcos Douglas wrote:
Please, see that:
http://lists.freepascal.org/lists/fpc-devel/2010-July/020699.html
http://lists.freepascal.org/lists/fpc-devel/2010-July/020791.html
http://lists.freepascal.org/lists/fpc-devel/2010-July/020856.html
http://lists.freepascal.org/lists/
On 26 July 2010 23:29, Marco van de Voort wrote:
>
> The whole namespace bit is make up as you go, that doesn't result in the
> best solutions. First think, then do.
Maybe I think and do so fast, you confuse it with thinking its one step. ;-)
G.
___
In our previous episode, Graeme Geldenhuys said:
> On 26 July 2010 22:57, Marco van de Voort wrote:
> >
> > That's where the problems are. A feature is more than just syntax.
>
> An a solution could come from a discussion, so what's your point?
That I don't subscribe to your first bit, that a so
On 26 July 2010 22:57, Marco van de Voort wrote:
>
> That's where the problems are. A feature is more than just syntax.
An a solution could come from a discussion, so what's your point?
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pas
On 26 July 2010 22:57, Florian Klämpfl wrote:
>
> What makes you think so? Which compiler patches did we reject so far?
Lets take some examples in the last few months alone. I had code for
the RTL. Iterators come to mind - denied. Then there was a patch for a
more cross-platform help type definit
In our previous episode, Florian Kl?mpfl said:
> > (referring to previous attempts to contribute code - which Macro
> > clearly said NO to).
>
> Where? I cannot rememeber any rejection of compiler contributions.
I can't remember refusing code. I can remember refusing some sub 10 lines
patches whe
Am 26.07.2010 23:00, schrieb Graeme Geldenhuys:
> On 26 July 2010 22:47, Florian Klämpfl wrote:
>>
>> The person who implementes, decides, so most of the discussion is a
>> waste of time.
>
>
> Then please send that memo to Macro, he clearly didn't get it
Where? I didn't read the whole thread b
On 26 July 2010 22:47, Florian Klämpfl wrote:
>
> The person who implementes, decides, so most of the discussion is a
> waste of time.
Then please send that memo to Macro, he clearly didn't get it
(referring to previous attempts to contribute code - which Macro
clearly said NO to).
[..you guys
In our previous episode, Graeme Geldenhuys said:
> The namespaces idea needs to be discussed, a syntax need to be
> developed if needed, and a consensus must be reached BEFORE it can be
> implemented.
That's where the problems are. A feature is more than just syntax.
__
Am 26.07.2010 22:51, schrieb Graeme Geldenhuys:
> Otherwise I would have implemented many things already
> - but I doubt any of those would be applied.
What makes you think so? Which compiler patches did we reject so far?
___
fpc-devel maillist - fpc-d
On 26 July 2010 23:01, Nikolai Zhubr wrote:
> sure you know this very well. So, wouldn't it be better to first prepare a
> consistent formal proposal/description (like Marco suggested) or even a
> patch - and then if it is clearly good for all and is nevertheless rejected
> for no reason - only af
On 26 July 2010 22:24, Florian Klämpfl wrote:
>
> I've enough great ideas and suggestions but not enought to implement
> them unfortunatly. So better come up with code instead of endless ideas.
Florian, such comments don't help either! As Jonas and Marco keeps
saying, FPC development is a two-way
Am 26.07.2010 22:36, schrieb Marcos Douglas:
> and if we send the code and, even like that, it
> will not approved?
Within 17 years of FPC, no contribution to the compiler was completely
rejected, so no need to worry. And if one still worries: just write a
paper/wiki page explaining what shall be
27.07.2010 0:15, Graeme Geldenhuys:
On 26 July 2010 18:30, Marco van de Voort wrote:
If your idea was really so great, and this was really a solution, why don't
you simply describe it?
Yeah, yeah, we all know you have a terrible time maintaining FPC. Most
people can maintain legacy software,
On Mon, Jul 26, 2010 at 5:24 PM, Florian Klämpfl wrote:
> Am 26.07.2010 22:15, schrieb Graeme Geldenhuys:
>>
>> Just offering negative comments and shooting down ideas, do not help
>> this or any other discussion. If you give negative comments, try back
>> it up with an additional suggestion or tw
2010/7/26 Adem :
> I am not sure if this has been proposed, but wouldn't it make life a lot
> easier if we considered the 'namespaces' metaphor as something that
> resembles to URLs.
>
> Here is an example:
>
> In the project file, I'd like to have these declarations:
>
> namespace Lazarus readonl
Am 26.07.2010 22:15, schrieb Graeme Geldenhuys:
>
> Just offering negative comments and shooting down ideas, do not help
> this or any other discussion. If you give negative comments, try back
> it up with an additional suggestion or two.
I've enough great ideas and suggestions but not enought t
I am not sure if this has been proposed, but wouldn't it make life a
lot easier if we considered the 'namespaces' metaphor as something that
resembles to URLs.
Here is an example:
In the project file, I'd like to have these declarations:
namespace Lazarus readonly url 'C:/Program Files/Lazar
On 26 July 2010 18:30, Marco van de Voort wrote:
>
> If your idea was really so great, and this was really a solution, why don't
> you simply describe it?
Yeah, yeah, we all know you have a terrible time maintaining FPC. Most
people can maintain legacy software, and still see chance for adding
an
On Mon, Jul 26, 2010 at 1:51 PM, Martin wrote:
> On 26/07/2010 17:32, Marcos Douglas wrote:
>>
using IN and ALIAS,
- the developper should still attempt to use names that he hopes to be
unique: MyFooStrUtils,instead of StrUtils
- only in the rare case of a conflict, action is n
26.07.2010 13:04, Michael Schnell:
On 07/24/2010 06:55 PM, Nikolai Zhubr wrote:
I think only FS selector (and/or descriptor) varies across threads.
Seemingly not the selector value (the FS content seems to stay constant
among the threads), but the table entry it selects.
You are right. Just
On 26/07/2010 17:34, Marco van de Voort wrote:
No it won't. There only will be graeme.geldenhuys.fpgui.constants
What a coincidence => I have a unit in one of my projects
unit GraemeGeldenhuysFpguiConstants;
SCNR
Martin
___
fpc-devel maillist -
On 26/07/2010 17:32, Marcos Douglas wrote:
using IN and ALIAS,
- the developper should still attempt to use names that he hopes to be
unique: MyFooStrUtils,instead of StrUtils
- only in the rare case of a conflict, action is needed
Well... now that I know how you want those "in 'LCL'"
On Mon, Jul 26, 2010 at 1:41 PM, Sven Barth wrote:
> On 26.07.2010 18:29, Marcos Douglas wrote:
>>
>> On Mon, Jul 26, 2010 at 1:23 PM, Sven Barth
>> wrote:
>>>
>>> On 26.07.2010 18:13, Marcos Douglas wrote:
On Mon, Jul 26, 2010 at 12:18 PM, Martin wrote:
>
> [snip]
> In f
On 26/07/2010 17:29, Marcos Douglas wrote:
Not exactly. Yours is a bit different:
uses
Foo in 'whereever/the/lcl/dir/is' as FooLCL,
Foo in 'whereever/the/rtl/dir/is' as FooRTL;
The idea of Martin's concept is to define "aliases" for the search paths as
well so that you can change them by
On 26.07.2010 18:29, Marcos Douglas wrote:
On Mon, Jul 26, 2010 at 1:23 PM, Sven Barth wrote:
On 26.07.2010 18:13, Marcos Douglas wrote:
On Mon, Jul 26, 2010 at 12:18 PM, Martinwrote:
[snip]
In fact if the existing
uses Foo in 'dir';
could be extended to allow a package or similar
uses
In our previous episode, Graeme Geldenhuys said:
> On 25 July 2010 20:25, Martin wrote:
> > I simple have said and do say, that it does not solve the original issue of
> > this discussion.
>
> Speaking of the hijacked thread only, with correct namespace
> implementation, it can indeed solve the pr
On Mon, Jul 26, 2010 at 1:27 PM, Sven Barth wrote:
> On 26.07.2010 18:17, Martin wrote:
>>
>> That can be interpreted as following:
>>
>> The search path becomes the namespace => by defining an alias for a
>> search path
>> -Fu=LCL::/path/to/lcl
>> the alias "LCL" has been defined, to include all
In our previous episode, Graeme Geldenhuys said:
> > I think that chance is overestimated, unless you use very familiar
> > identifiers (like "buttons").
>
> Visual objects are not the only area such conflicts occur. Creating
> your own Container classes, Process controls etc allows for a lot more
On Mon, Jul 26, 2010 at 1:23 PM, Sven Barth wrote:
> On 26.07.2010 18:13, Marcos Douglas wrote:
>>
>> On Mon, Jul 26, 2010 at 12:18 PM, Martin wrote:
>>>
>>> [snip]
>>> In fact if the existing
>>> uses Foo in 'dir';
>>>
>>> could be extended to allow a package or similar
>>> uses Foo in 'LCL'
>>>
On 26.07.2010 18:17, Martin wrote:
That can be interpreted as following:
The search path becomes the namespace => by defining an alias for a
search path
-Fu=LCL::/path/to/lcl
the alias "LCL" has been defined, to include all unist in this search path
using a unit from a anmespace is done with th
On 26.07.2010 18:13, Marcos Douglas wrote:
On Mon, Jul 26, 2010 at 12:18 PM, Martin wrote:
[snip]
In fact if the existing
uses Foo in 'dir';
could be extended to allow a package or similar
uses Foo in 'LCL'
and an alias directive would be introduced, then it was all solved too
uses Foo in 'l
On Mon, Jul 26, 2010 at 12:34 PM, Sven Barth
wrote:
> [snip]
>> But that can be done for prefixes too:
>> fpc -unitprefix=My Utils.pas
>>
>
> In theory, yes, but Delphi allows more than one prefix for the unit name
> (see
> http://docwiki.embarcadero.com/RADStudio/en/Using_Namespaces_with_Delphi )
That can be interpreted as following:
The search path becomes the namespace => by defining an alias for a
search path
-Fu=LCL::/path/to/lcl
the alias "LCL" has been defined, to include all unist in this search path
using a unit from a anmespace is done with the existing "IN" operator
(whic
On Mon, Jul 26, 2010 at 12:18 PM, Martin wrote:
> [snip]
> In fact if the existing
> uses Foo in 'dir';
>
> could be extended to allow a package or similar
> uses Foo in 'LCL'
>
> and an alias directive would be introduced, then it was all solved too
>
> uses Foo in 'lcl' alias 'FooLCL', Foo in 'R
On 26/07/2010 16:49, Martin wrote:
-Fu=/path/to/lcl // already existent, unit search path
-Fa-LCL:/path/to/lcl // define the LCL alias
should have been an = sign
-Fa=LCL:/path/to/lcl // define the LCL alias
alias ends at the ":" or whatecer separator is defined.
-
Thinking about it
On 26/07/2010 16:45, Sven Barth wrote:
On 26.07.2010 17:27, Martin wrote:
Replying to myself..
Using Aliases for unit names could be an alternative, that solves the
problem (conflicting unit names can be given different aliases)
And it would not require any new prefixes in the source or anythi
On 26.07.2010 17:40, Martin wrote:
On 26/07/2010 16:34, Sven Barth wrote:
It's not about not having to type the "fully qualified name", but
about not having to rename/prefix my own units, because they conflict
with an existing unit.
Ok, so that means:
If refering to the unit, or any element in
On 26.07.2010 17:27, Martin wrote:
Replying to myself..
Using Aliases for unit names could be an alternative, that solves the
problem (conflicting unit names can be given different aliases)
And it would not require any new prefixes in the source or anything. no
new meaning of a dot, separating
On 26/07/2010 16:34, Sven Barth wrote:
It's not about not having to type the "fully qualified name", but
about not having to rename/prefix my own units, because they conflict
with an existing unit.
Ok, so that means:
If refering to the unit, or any element in it, you always have to use
the full
On 26.07.2010 17:18, Martin wrote:
On 26/07/2010 15:55, Sven Barth wrote:
Hi!
So... continuing the thread were it belongs... in fpc-devel :P
On 26.07.2010 16:36, Marcos Douglas wrote:
On Mon, Jul 26, 2010 at 11:20 AM, Sven Barth
wrote:
What about that the compiler enforces that you use the
Replying to myself..
Using Aliases for unit names could be an alternative, that solves the
problem (conflicting unit names can be given different aliases)
And it would not require any new prefixes in the source or anything. no
new meaning of a dot, separating namespace and unit name
use
On 26/07/2010 15:55, Sven Barth wrote:
Hi!
So... continuing the thread were it belongs... in fpc-devel :P
On 26.07.2010 16:36, Marcos Douglas wrote:
On Mon, Jul 26, 2010 at 11:20 AM, Sven Barth
wrote:
What about that the compiler enforces that you use the fully
qualified name
if you used i
On Mon, Jul 26, 2010 at 11:55 AM, Sven Barth
wrote:
> [snip]
>> So... maybe create a new directive like as {$NAMESPACE ON}
>>
>> eg.
>>
>> {$NAMESPACE ON}
>> unit strutils namespace my;
>>
>> With {$NAMESPACE ON} all units will have namespaces, unless FPC's units.
>
> Can you explain what you want
Hi!
So... continuing the thread were it belongs... in fpc-devel :P
On 26.07.2010 16:36, Marcos Douglas wrote:
On Mon, Jul 26, 2010 at 11:20 AM, Sven Barth
wrote:
What about that the compiler enforces that you use the fully qualified name
if you used it in the uses?
Not only if you used it
FPC uses the same code with Win32 and with Linux X86/32. It does an
indirect call to some external function. So this supposedly is less
efficient than Delphi, GnuC or M$ C.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lis
On 07/26/2010 02:51 PM, Sergei Gorelkin wrote:
Michael Schnell wrote:
...
This is essentially the same code as with Delphi. Supposedly as with
Delphi [__tls_index (417328h) ] is always 0 with normal applications.
(no idea what this is useful for)
The TLS index is allocated by a call to TlsA
Michael Schnell wrote:
...
This is essentially the same code as with Delphi. Supposedly as with
Delphi [__tls_index (417328h) ] is always 0 with normal applications.
(no idea what this is useful for)
The TLS index is allocated by a call to TlsAlloc at application startup. It will be zero for
Op 2010-07-26 13:20, Sven Barth het geskryf:
>
> Would you mind adding this idea to the Namespace-thread on fpc-pascal,
> so that there is one place of discussion?
It also doesn't help that I accidentally posted the new thread to the
fpc-pascal mailing list, instead of the intended fpc-devel mai
M$ C on Win32 (X86/32), using Visual Studio.
declspec(thread) int ithread;
ithread = 1;
results in
mov eax, dword ptr [__tls_index (417328h) ]
mov ecx, dword ptr fs:[2Ch]
mov edx, dword ptr [ecx,+eax*4]
mov dword pth[edx+104h],1
This is essentially the same code as with Delphi. Supp
Hi!
On 26.07.2010 12:11, Hans-Peter Diettrich wrote:
If ever, I'd agree about (project wide) symbolic names for library
directories. Then the file location is given once, in the program or
package settings (search path), easily adoptable to any installation,
and then a package unit can be qualif
Jonas Maebe schrieb:
I simply don't like the idea of having one big parser class blob spread
over multiple include files.
Especially since in the past several people spent a lot of time on breaking
cyclic dependencies and organising everything nicely into separate units (both
for the parser
Graeme Geldenhuys schrieb:
Op 2010-07-26 02:45, Hans-Peter Diettrich het geskryf:
How should that work? How to distinguish between utils.pas and
utils.pas, in "using utils;"?
I'm thinking in the line of working with something like Lazarus Packages.
This is not limited to Lazarus only though. W
Florian Klaempfl schrieb:
When a parser is designed to work with exactly one scanner, why should
it not inherit from it?
Well, with the same argument one could stuff all code in one source file
and don't separate anything in units.
Encapsulation requires some separation.
Having parser and
As recommended starting a new message thread
Reverse engineering:
threadvar ithread: integer;
ithread := 1;
or in "C":
__thread ithread int:
ithread = 1;
Delphi, Win32 on X86/32 (stripping off additional offsets that seemingly
are always 0 in normal applications):
mov edx, FS: $2c
mov
On 07/26/2010 11:41 AM, Sven Barth wrote:
Win64 uses GS instead of FS for the TEB and everything else stays the
same. In fact FS and GS (and to some extend CS) are the only selectors
actively used by the x86_64 platform, but - if I understand that
correctly - they can only be set up from rin
Hi!
Am 26.07.2010 11:22, schrieb Michael Schnell:
Maybe Win64 uses some "Selector" mechanism (similar as ) so that there
are no different Selector-Register values in different threads.
Win64 uses GS instead of FS for the TEB and everything else stays the
same. In fact FS and GS (and to some e
On 07/24/2010 06:52 PM, Nikolai Zhubr wrote:
IMHO the question is not how to avoid using FS trick altogether (which
is of course possible, right), but on the contrary, how to reliably
employ it in order to avoid wasting some more usefull registers and
excessive OS calls.
It's only possible
Hi!
Am 26.07.2010 11:07, schrieb Michael Schnell:
On 07/26/2010 10:28 AM, Michael Schnell wrote:
mov edx, fs:[4]
Typo: $2C, instead of $4
I already wondered what "crap" Delphi is doing here :P
Btw: would you mind to start a new thread about threadvar
implementation, because this discussio
On 07/24/2010 05:12 PM, Hans-Peter Diettrich wrote:
In the meantime I found one possible use for threadvars: when some
subroutine can be called from different threads, it may want to
retrieve the thread context, e.g. the thread object itself. Right?
Yep. But of course you can do multiple thre
On 07/26/2010 10:28 AM, Michael Schnell wrote:
mov edx, fs:[4]
Typo: $2C, instead of $4
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 07/25/2010 10:22 AM, Hans-Peter Diettrich wrote:
The main thread may have an index of zero, but every other thread can
have an different index. This can be tested or debugged only with real
threads.
Done (with Turbo Delphi): see above.
Trying to do tests with FP, gnuC and M$ C.
-Michael
On 07/24/2010 06:55 PM, Nikolai Zhubr wrote:
I think only FS selector (and/or descriptor) varies across threads.
Seemingly not the selector value (the FS content seems to stay constant
among the threads), but the table entry it selects.
-Michael
__
On 07/24/2010 05:46 PM, Hans-Peter Diettrich wrote:
I wonder what TlsIndex here is?
In a simple test I did, it's 0.
BTW: FS is always the same value ($3B), Obviously Windows changes the
table entry value, the selector $3B points to.
-Michael
_
On 26 Jul 2010, at 10:43, Florian Klaempfl wrote:
> I simply don't like the idea of having one big parser class blob spread
> over multiple include files.
Especially since in the past several people spent a lot of time on breaking
cyclic dependencies and organising everything nicely into separa
Am 26.07.2010 02:22, schrieb Hans-Peter Diettrich:
> Florian Klämpfl schrieb:
>
>>> Parser
>>> now is derived from the tscannerfile class.
>>
>> This is a really ugly design OOP wise ...
>
> When a parser is designed to work with exactly one scanner, why should
> it not inherit from it?
Well, w
On 07/24/2010 03:16 PM, Florian Klämpfl wrote:
Delphi does not use a segment register for threadvar handling but OS calls.
sorry but this is not true
Turbo Delphi:
code:
var test integer;
threadvar threadtest: integer;
test := 1;
threadtest := 2;
compiles to
mov [$...], $1
call @G
Op 2010-07-26 02:45, Hans-Peter Diettrich het geskryf:
>
> How should that work? How to distinguish between utils.pas and
> utils.pas, in "using utils;"?
I'm thinking in the line of working with something like Lazarus Packages.
This is not limited to Lazarus only though. When I talk about a "laz
On 07/24/2010 04:55 AM, Hans-Peter Diettrich wrote:
Moreover the point with threadvars is that threads that use the same
code see different values in the same threadvar. These threads of
course can't use different registers to access them as the run the
same code.
Consider a threadvar as a f
On 07/24/2010 04:55 AM, Hans-Peter Diettrich wrote:
With most archs all static variables (such as globals and threadvars)
always are accessed relative to a register. With X86/32 globals and
statics are allocated relative to DS,
Here the segment register is somewhat irrelevant, since each map
On 07/24/2010 04:55 AM, Hans-Peter Diettrich wrote:
I see no difference here. IMO the segment register is used implicitly
in thread API calls, with no further use by application code. Every
thread has one "slot" reserved in the OS-maintained data structure,
where it can store one private val
86 matches
Mail list logo
