Daniël Mantione schrieb:
Yes, but in a multi-cpu system giving up the timeslice is a very bad
idea, because the lock might be released a few clock cycles later by the
other cpu; you would waste the rest of time slice while you could be
crunching.
IMO the default implementation should work on
On 06/24/2010 12:17 PM, Michael Schnell wrote:
> Maybe automatically
> detecting the arch and using the best possible code for atomicness would
> be a good way to go.
>
Even better: as you found the "fixed addresses" implementations same
should be used having the Kernel automatically provide th
On 06/24/2010 12:23 PM, Henry Vermaak wrote:
>
> Which exposes the user helpers here:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l767
>
>
Yep.
>
"These are segment of kernel provi
On 24 June 2010 10:05, Henry Vermaak wrote:
>
> The linux specific code is here:
>
> http://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/ports/sysdeps/unix/sysv/linux/arm/nptl/bits/atomic.h?rev=3063&view=markup
>
> It relies completely on the kernel.
Which exposes the user helpers here:
http://git.k
On 06/24/2010 11:21 AM, Henry Vermaak wrote:
> SMP is not supported by the kernel for arch < armv6.
>
Great !
So nothing serious needs to be done about that. Maybe automatically
detecting the arch and using the best possible code for atomicness would
be a good way to go.
-Michael
_
On 06/24/2010 11:23 AM, Florian Klaempfl wrote:
>
> But it is not used dynamically: if you compile for arm linux, you get
> the ARMv5 code path even if the code runs on ARMv6+
>
I see.
I suppose somewhere you can define that you want RMv6+ code. I would do
this whenever possible.
Maybe providi
On 06/24/2010 11:05 AM, Henry Vermaak wrote:
>
> /* Atomic compare and exchange. These sequences are not actually atomic;
>there is a race if *MEM != OLDVAL and we are preempted between the two
>swaps. However, they are very close to atomic, and are the best that a
>pre-ARMv6 implemen
Michael Schnell schrieb:
> On 06/24/2010 10:23 AM, Florian Klaempfl wrote:
>> Nobody provided either code yet which makes dynamic use of strex/ldex
>> as newer arms provide as I did e.g. for move using pld if available
>> because I needed it.
>>
> The code using strex/ldex is in place for ARMv6
On 24 June 2010 09:16, Michael Schnell wrote:
> On 06/24/2010 10:10 AM, Daniël Mantione wrote:
>>
>> Yes, but in a multi-cpu system giving up the timeslice is a very bad
>> idea, because the lock might be released a few clock cycles later by
>> the other cpu; you would waste the rest of time slice
On 06/24/2010 10:23 AM, Florian Klaempfl wrote:
> Nobody provided either code yet which makes dynamic use of strex/ldex
> as newer arms provide as I did e.g. for move using pld if available
> because I needed it.
>
The code using strex/ldex is in place for ARMv6 and ARMv7. I don't doubt
that sa
On 24 June 2010 09:00, Michael Schnell wrote:
> On 06/23/2010 09:26 PM, Florian Klämpfl wrote:
>> I'am sure if it's a problem for somebody, he will find a solution and
>> send a patch.
>>
> As the swap instruction seems to be the only atomic memory operation ARM
> lower than v6 can do, there is no
Michael Schnell schrieb:
> On 06/24/2010 10:02 AM, Florian Klaempfl wrote:
>> Well, yes, you shouldn't simply use locked operations in a single cpu
>> environment, your application should provide different algorithms for
>> single and multi cpu/threaded environments if the application really
>> con
On 06/24/2010 10:10 AM, Daniël Mantione wrote:
>
> Yes, but in a multi-cpu system giving up the timeslice is a very bad
> idea, because the lock might be released a few clock cycles later by
> the other cpu; you would waste the rest of time slice while you could
> be crunching
Of course you are rig
On 06/24/2010 10:02 AM, Florian Klaempfl wrote:
> Well, yes, you shouldn't simply use locked operations in a single cpu
> environment, your application should provide different algorithms for
> single and multi cpu/threaded environments if the application really
> contains speed critical code requi
Op Thu, 24 Jun 2010, schreef Michael Schnell:
On 06/23/2010 05:35 PM, Daniël Mantione wrote:
It's a non-issue. If you set a thread realtime you know what you are
doing and can take care you give up the CPU when feasible, or you
simply don't enter mutuxes shared with non-realtime threads.
I
Michael Schnell schrieb:
> On 06/23/2010 05:35 PM, Daniël Mantione wrote:
>> It's a non-issue. If you set a thread realtime you know what you are
>> doing and can take care you give up the CPU when feasible, or you
>> simply don't enter mutuxes shared with non-realtime threads.
>
> I don't agree.
On 24 Jun 2010, at 09:27, Michael Schnell wrote:
[ARMv5 and lower atomic exchange]
If there is no other way with this arch but an
active spinning lock,
There is indeed none.
the blocked thread should at least give up it's
current time slice before retrying to get the lock, so that the
blo
On 06/23/2010 09:26 PM, Florian Klämpfl wrote:
> I'am sure if it's a problem for somebody, he will find a solution and
> send a patch.
>
As the swap instruction seems to be the only atomic memory operation ARM
lower than v6 can do, there is no possible workaround in user space
software.
For a s
On 06/23/2010 06:04 PM, Henry Vermaak wrote:
>
> That only means that it doesn't send the lock signal to the external
> memory manager, so you can't have a multi processor implementation
> using this processor. It doesn't affect the working of the swp
> instruction.
>
I understand the "external me
On 06/23/2010 05:35 PM, Daniël Mantione wrote:
>
> It's a non-issue. If you set a thread realtime you know what you are
> doing and can take care you give up the CPU when feasible, or you
> simply don't enter mutuxes shared with non-realtime threads.
I don't agree.
If the RTL provides a method, i
Michael Schnell schrieb:
From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You must take care to ensure that control of the memory is not
removed from the ARM
processor while it is performing this instruction.
This seems to apply
Michael Schnell schrieb:
> On 06/23/2010 04:49 PM, Henry Vermaak wrote:
>> No, SWP is atomic, so the implementation looks good (at a glance).
>>
>
> Seemingly not on all ARM sub-archs:
>
>>From some ARM manual:
>
> The ARM7500FE does not use the lock feature available in the ARM701
> macroce
On 23/06/10 16:19, Michael Schnell wrote:
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
No, SWP is atomic, so the implementation looks good (at a glance).
Seemingly not on all ARM sub-archs:
From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
mac
Michael Schnell wrote:
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
No, SWP is atomic, so the implementation looks good (at a glance).
Seemingly not on all ARM sub-archs:
>From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You must
Op Wed, 23 Jun 2010, schreef Michael Schnell:
On 06/23/2010 05:18 PM, Mattias Gaertner wrote:
What system has such an unfair scheduler?
A "fair" Scheduler only can be fair if time slices are to be managed. If
you set a thread to a "realtime priority" (OK, you need to be root to be
allowed t
Sorry if I have been sounding rude:(.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 06/23/2010 05:18 PM, Mattias Gaertner wrote:
> What system has such an unfair scheduler?
A "fair" Scheduler only can be fair if time slices are to be managed. If
you set a thread to a "realtime priority" (OK, you need to be root to be
allowed to do that :) ) it's priority is above all the norma
On 06/23/2010 05:15 PM, Micha Nelissen wrote:
>
> Priority inversion? Isn't this a problem with any InterlockedC/E?
>
Priority inversion here leads to an unavoidable deadlock. "Normal"
priority inversion only reduces the priority of a high priority thread
to that of a lower priority thread that hol
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
>
> No, SWP is atomic, so the implementation looks good (at a glance).
>
Seemingly not on all ARM sub-archs:
>From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You must take care to ensure that
On Wed, 23 Jun 2010 17:12:29 +0200
Michael Schnell wrote:
> On 06/23/2010 04:49 PM, Henry Vermaak wrote:
> > On 23/06/10 15:26, Michael Schnell wrote:
> >>
> >> Other ARMs (including thumb2) uses a loop with result compare. AFAIK
> >> this does not work reliably. I am not sure it it's really true
Michael Schnell wrote:
unfortunately we are in a "realtime" system and the priority of thread 2
is set higher than that of thread 1 and thus thread 1 never gets a CPU
Priority inversion? Isn't this a problem with any InterlockedC/E?
Micha
___
fpc-dev
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
> On 23/06/10 15:26, Michael Schnell wrote:
>>
>> Other ARMs (including thumb2) uses a loop with result compare. AFAIK
>> this does not work reliably. I am not sure it it's really true that ARM
>
> No, SWP is atomic, so the implementation looks good (at
On 06/23/2010 04:38 PM, Florian Klaempfl wrote:
>
> I can only speak for sparc (because I implemented them initially): they
> are implemented according to official sparc docs. Do you know more then
> them?
>
Sorry if I have been sounding rude :(.
I learned that If there is no hardware support,
On 23/06/10 15:26, Michael Schnell wrote:
Other ARMs (including thumb2) uses a loop with result compare. AFAIK
this does not work reliably. I am not sure it it's really true that ARM
No, SWP is atomic, so the implementation looks good (at a glance).
Henry
_
Michael Schnell schrieb:
> PPC, PPC64, Sparc: loop: not reliable
I can only speak for sparc (because I implemented them initially): they
are implemented according to official sparc docs. Do you know more then
them?
___
fpc-devel maillist - fpc-devel@li
On 23 Jun 2010, at 16:26, Michael Schnell wrote:
PPC, PPC64, Sparc: loop: not reliable
interlocked* is implemented correctly in the RTL and functions 100%
reliably on the above architectures. Please don't make such
categorical statements if you are unfamiliar with the architectures
(and
On 06/23/2010 03:56 PM, Henry Vermaak wrote:
>
> We've got this already, then:
>
> http://www.freepascal.org/docs-html/rtl/system/interlockedcompareexchange.html
>
nice !
X86, X68-64: good.
"ARMV6" uses ldrex (seemingly = "load locked"): good
Other ARMs (including thumb2) uses a loop with r
On 23 June 2010 13:58, Michael Schnell wrote:
> On 06/23/2010 02:45 PM, Henry Vermaak wrote:
>> I think you'll first have to worry porting fpc to those architectures.
>>
> Right you are :)
>
> But anyway, if not using libc, you need to do the FUTEX user space part
> in Pascal/Assembler
>
> - With
Marco van de Voort schrieb:
The Kylix-like addition of an C compiler would help to solve such
issues, that arise from the use of *any* C code with FPC.
Well, since this is about a maintenance problem, it would only solve
it if the maintenance of the C compiler would be lower than the
maintenan
Am 23.06.2010 15:34, schrieb Henry Vermaak:
On 23 June 2010 14:22, Henry Vermaak wrote:
On 23 June 2010 14:13, Daniël Mantione wrote:
Op Wed, 23 Jun 2010, schreef Henry Vermaak:
A futex syscall doesn't know anything about threads, it's for locking.
Perhaps I'm misunderstanding you?
I ha
On 23 June 2010 14:22, Henry Vermaak wrote:
> On 23 June 2010 14:13, Daniël Mantione wrote:
>>
>>
>> Op Wed, 23 Jun 2010, schreef Henry Vermaak:
>>
>>> A futex syscall doesn't know anything about threads, it's for locking.
>>> Perhaps I'm misunderstanding you?
>>
>> I have should have written "fu
On 23 June 2010 14:13, Daniël Mantione wrote:
>
>
> Op Wed, 23 Jun 2010, schreef Henry Vermaak:
>
>> A futex syscall doesn't know anything about threads, it's for locking.
>> Perhaps I'm misunderstanding you?
>
> I have should have written "futex" instead of "threads". With a Futex, you
> only cal
On 06/23/2010 03:08 PM, Henry Vermaak wrote:
> A futex syscall doesn't know anything about threads, it's for locking.
> Perhaps I'm misunderstanding you?
>
The Futex syscall does not lock a Mutex at all. It's a helper for the
user space locking action and performs the putting a thread to sleep
Op Wed, 23 Jun 2010, schreef Henry Vermaak:
A futex syscall doesn't know anything about threads, it's for locking.
Perhaps I'm misunderstanding you?
I have should have written "futex" instead of "threads". With a Futex, you
only call the Futex syscall, if the Futex is locked. You still have
On 06/23/2010 03:00 PM, Henry Vermaak wrote:
> Why would you want to do that? Just use the futex syscall.
Here you are definitely wrong.
Futex is all about _not_ doing a syscall (i.e. change from user space to
Kernel space and back) but doing the Mutex operation in user space, if
possible (i.e. i
On 23 June 2010 14:03, Daniël Mantione wrote:
>
>
> Op Wed, 23 Jun 2010, schreef Henry Vermaak:
>
>> On 23 June 2010 13:58, Michael Schnell wrote:
>>>
>>> On 06/23/2010 02:45 PM, Henry Vermaak wrote:
I think you'll first have to worry porting fpc to those architectures.
>>> Right y
Op Wed, 23 Jun 2010, schreef Henry Vermaak:
On 23 June 2010 13:58, Michael Schnell wrote:
On 06/23/2010 02:45 PM, Henry Vermaak wrote:
I think you'll first have to worry porting fpc to those architectures.
Right you are :)
But anyway, if not using libc, you need to do the FUTEX user spac
On 23 June 2010 13:58, Michael Schnell wrote:
> On 06/23/2010 02:45 PM, Henry Vermaak wrote:
>> I think you'll first have to worry porting fpc to those architectures.
>>
> Right you are :)
>
> But anyway, if not using libc, you need to do the FUTEX user space part
> in Pascal/Assembler
Why would
On 06/23/2010 02:45 PM, Henry Vermaak wrote:
> I think you'll first have to worry porting fpc to those architectures.
>
Right you are :)
But anyway, if not using libc, you need to do the FUTEX user space part
in Pascal/Assembler
- With X86 using the appropriate assembler instructions (such as
On 23 June 2010 13:23, Michael Schnell wrote:
>
> If they show up that does not mean there really is a valid
> implementation. I don't know which archs are provided with the "Linus
> Tree", but at least with some "embedded" Kernels trees there only is
> some dummy code, just providing an error.
On 06/23/2010 01:37 PM, Henry Vermaak wrote:
>
> I still can't find which arches miss futex, and I can't find this
> information in the manpages, either. Can you point me to where you've
> found this information?
At least in the Linux Kernel Mailing list there are several discussions
on Futex (e.
On 06/23/2010 01:21 PM, Henry Vermaak wrote:
> There are no magic NPTL APIs: both NPTL and LinuxThreads use the
> "clone" system call.
Yep. Additional "clone flags" have been added with newer Kernels (see
"man clone").
Moreover for NPTL there are thread IDs additional to process IDs Same
can be o
On 06/22/2010 03:12 PM, Henry Vermaak wrote:
>
> No, the syscall api is very stable, so minimum maintenance is
> required. Which architectures don't provide futex? I'm not aware of
> any.
>
The FUTEX Kernel API only makes sense, if the arch provides the
appropriate atomic operations to perform
In our previous episode, Hans-Peter Diettrich said:
> > start with a translated glibc in a good month), but the continuous
> > maintenance (for every distribution separately, since they could use
> > different kernels, options etc) , and interoperability with C code would be
> > killing.
>
> The K
On 23/06/10 12:13, Michael Schnell wrote:
On 06/22/2010 02:55 PM, Michael Van Canneyt wrote:
For the kernel interface: Not so much. (on some archs, FUTEX is missing).
Yep.
I still can't find which arches miss futex, and I can't find this
information in the manpages, either. Can you point
On 23/06/10 11:44, Michael Schnell wrote:
On 06/22/2010 05:18 PM, Florian Klaempfl wrote:
At least according to Linus, the kernel api/syscall interface will never
break.
Regarding Threads, as far as I understand, the thread aware APIs (e.g.
NPTL and FUTEX) have been added, while the other APIs
On 06/22/2010 02:57 PM, Graeme Geldenhuys wrote:
>
>> Of course you can avoid using the library, do the stuff in Pascal and
>> directly access the Kernel API, but this might be dangerous in case the
>> API might be modified some time in the future
>>
> Wouldn't the same apply to the pthreads l
On 06/22/2010 02:55 PM, Michael Van Canneyt wrote:
>
>
> For the kernel interface: Not so much. (on some archs, FUTEX is missing).
Yep.
>
> The problem starts if you start linking to C libraries. In that case
> you're
> pretty much forced to use pthreads; each distribution can make different
> choi
On 06/22/2010 02:49 PM, Graeme Geldenhuys wrote:
> http://linas.org/linux/threads-faq.html
This is _very_ old (1996).
they say:
"Kernel-Threads
Kernel-level threads often are implemented in the kernel using several
tables"
This might be true, but we now have a ubiquitous and stable NPTL
implement
On 06/22/2010 03:35 PM, Henry Vermaak wrote:
>
> So maybe the fpc syscall interface needs to be updated. Can you give
> any examples of what got reworked?
I don't suppose we already have NPTL and FUTEX, as same are used by
libc, anyway. If we want perfect performance and good (Posix-like)
behavi
On 06/22/2010 05:18 PM, Florian Klaempfl wrote:
> At least according to Linus, the kernel api/syscall interface will never
> break.
>
Regarding Threads, as far as I understand, the thread aware APIs (e.g.
NPTL and FUTEX) have been added, while the other APIs were not affected.
(No wonder, as I u
Marco van de Voort schrieb:
The problem is not the programming (since a dedicated person could probably
start with a translated glibc in a good month), but the continuous
maintenance (for every distribution separately, since they could use
different kernels, options etc) , and interoperability w
Op Wed, 23 Jun 2010, schreef Graeme Geldenhuys:
Op 2010-06-22 15:31, Marco van de Voort het geskryf:
Same problem. You still have to interface with the kernel, and it would be
incompatible with C libraries that use threads.
Well, if I don't use C libraries (only Object Pascal code), then i
Op 2010-06-22 15:31, Marco van de Voort het geskryf:
>
> Same problem. You still have to interface with the kernel, and it would be
> incompatible with C libraries that use threads.
Well, if I don't use C libraries (only Object Pascal code), then it should
still be beneficial. I can then write p
On 22 June 2010 21:31, Micha Nelissen wrote:
> Marco van de Voort wrote:
>>
>> Huh? Do stock Linux kernels still support a.out? Since afaik ELF was only
>> added in
>> 1.1.52 ?
>
> It's a kernel option to support it. Most distro's choose "module" here I
> think? (Autodetect when used)
Yes, it's B
Marco van de Voort wrote:
Huh? Do stock Linux kernels still support a.out? Since afaik ELF was only added
in
1.1.52 ?
It's a kernel option to support it. Most distro's choose "module" here I
think? (Autodetect when used)
Micha
___
fpc-devel mailli
In our previous episode, Florian Kl?mpfl said:
> > In our previous episode, Marco van de Voort said:
> >>> At least according to Linus, the kernel api/syscall interface will never
> >>> break.
> >
> >> They will just not implement new calls on new archs ? :-)
> >
> > Euh, old calls obviously.
>
Marco van de Voort schrieb:
> In our previous episode, Marco van de Voort said:
>>> At least according to Linus, the kernel api/syscall interface will never
>>> break.
>
>> They will just not implement new calls on new archs ? :-)
>
> Euh, old calls obviously.
Well, adding a new arch is not brea
In our previous episode, Henry Vermaak said:
> > At least according to Linus, the kernel api/syscall interface will never
> > break.
>
> Never say never, things will be added, but not taken away. There are
> some very old programs that still run fine on new kernels. I've read
> that someone has
On 22 June 2010 16:18, Florian Klaempfl wrote:
> Marco van de Voort schrieb:
>> In our previous episode, Henry Vermaak said:
The cure is ten times more difficult than the problem. (namely that the
>>> That seems quite clear.
>>>
Libc breaks often, but I'm sure that a native lib will brea
On 22 June 2010 16:15, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
>> > The cure is ten times more difficult than the problem. (namely that the
>>
>> That seems quite clear.
>>
>> > Libc breaks often, but I'm sure that a native lib will break much more
>>
>> I certainl
In our previous episode, Marco van de Voort said:
> >
> > At least according to Linus, the kernel api/syscall interface will never
> > break.
> They will just not implement new calls on new archs ? :-)
Euh, old calls obviously.
___
fpc-devel maillist
In our previous episode, Florian Klaempfl said:
> > In our previous episode, Henry Vermaak said:
> >>> The cure is ten times more difficult than the problem. (namely that the
> >> That seems quite clear.
> >>
> >>> Libc breaks often, but I'm sure that a native lib will break much more
> >> I certai
Marco van de Voort schrieb:
> In our previous episode, Henry Vermaak said:
>>> The cure is ten times more difficult than the problem. (namely that the
>> That seems quite clear.
>>
>>> Libc breaks often, but I'm sure that a native lib will break much more
>> I certainly haven't experienced this lib
In our previous episode, Henry Vermaak said:
> > The cure is ten times more difficult than the problem. (namely that the
>
> That seems quite clear.
>
> > Libc breaks often, but I'm sure that a native lib will break much more
>
> I certainly haven't experienced this libc that breaks often.
Keep
On 22 June 2010 15:21, Marco van de Voort wrote:
>
> The cure is ten times more difficult than the problem. (namely that the
That seems quite clear.
> Libc breaks often, but I'm sure that a native lib will break much more
I certainly haven't experienced this libc that breaks often. Does
that m
In our previous episode, Henry Vermaak said:
> > Yes. And 99% of the thread using programs also use other C libs that use
> > libc anyway (*)
>
> So, to answer your question above about why we need a native one: so
> we can do away with the libc dependency.
In 0.1% of the programs. The rest does
On 22 June 2010 14:46, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
>> >
>> > Why would you need a native one in the first place?
>>
>> I was under the impression that fpc uses libc to implement threads on
>> unix. Is this not the case?
>
> Yes. And 99% of the thread u
In our previous episode, Henry Vermaak said:
> >
> > Why would you need a native one in the first place?
>
> I was under the impression that fpc uses libc to implement threads on
> unix. Is this not the case?
Yes. And 99% of the thread using programs also use other C libs that use
libc anyway (*
On 22 June 2010 14:38, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
>> >> Why is that? ?I thought you could use anything, as long as it's posix
>> >> compliant?
>> >
>> > Good luck getting all the C libs to use your POSIX compatible threading
>> > model.
>>
>> The reas
In our previous episode, Henry Vermaak said:
> >> Why is that? ?I thought you could use anything, as long as it's posix
> >> compliant?
> >
> > Good luck getting all the C libs to use your POSIX compatible threading
> > model.
>
> The reason for creating a native threading implementations is that
In our previous episode, Henry Vermaak said:
> >> The syscall interface is very stable, so you wouldn't have to touch
> >> anything there. ?I haven't looked at the nptl source, yet, what do they
> >> use that changes between distros?
> >
> > The syscall interface now only uses a subset of relativel
On 22 June 2010 14:33, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
> [ Charset ISO-8859-1 unsupported, converting... ]
>> On 22 June 2010 13:55, Michael Van Canneyt wrote:
>> >
>> > The problem starts if you start linking to C libraries. In that case you're
>> > prett
On 22 June 2010 14:29, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
>> > The problem is not the programming (since a dedicated person could probably
>> > start with a translated glibc in a good month), but the continuous
>> > maintenance (for every distribution separate
In our previous episode, Henry Vermaak said:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 22 June 2010 13:55, Michael Van Canneyt wrote:
> >
> > The problem starts if you start linking to C libraries. In that case you're
> > pretty much forced to use pthreads;
>
> Why is that? I though
In our previous episode, Graeme Geldenhuys said:
> Op 2010-06-22 14:24, Marco van de Voort het geskryf:
> >
> > No, not straight away. That is technically impossible without integrating a
> > full C compiler, since POSIX requires to be able to read and interpret
>
> And what if one implements a n
In our previous episode, Henry Vermaak said:
> > The problem is not the programming (since a dedicated person could probably
> > start with a translated glibc in a good month), but the continuous
> > maintenance (for every distribution separately, since they could use
> > different kernels, options
On 22 Jun 2010, at 15:01, Henry Vermaak wrote:
On 22 June 2010 13:55, Michael Van Canneyt
wrote:
The problem starts if you start linking to C libraries. In that
case you're
pretty much forced to use pthreads;
Why is that? I thought you could use anything, as long as it's
posix compl
On 22 June 2010 14:16, Michael Van Canneyt wrote:
>
>
> On Tue, 22 Jun 2010, Henry Vermaak wrote:
>
>> On 22 June 2010 13:55, Michael Van Canneyt wrote:
>>>
>>> The problem starts if you start linking to C libraries. In that case
>>> you're
>>> pretty much forced to use pthreads;
>>
>> Why is tha
On Tue, 22 Jun 2010, Henry Vermaak wrote:
On 22 June 2010 13:55, Michael Van Canneyt wrote:
The problem starts if you start linking to C libraries. In that case you're
pretty much forced to use pthreads;
Why is that? I thought you could use anything, as long as it's posix compliant?
Be
On 22 June 2010 13:13, Michael Schnell wrote:
>
> Of course you can avoid using the library, do the stuff in Pascal and
> directly access the Kernel API, but this might be dangerous in case the
> API might be modified some time in the future or if it's different with
> different archs (e.g. some a
On 22 June 2010 13:55, Michael Van Canneyt wrote:
>
> The problem starts if you start linking to C libraries. In that case you're
> pretty much forced to use pthreads;
Why is that? I thought you could use anything, as long as it's posix compliant?
Henry
_
Op 2010-06-22 14:55, Michael Van Canneyt het geskryf:
>
> It would be nice to have a kernel interface, though. That way you could have
> threading support without pulling in libc.
Exactly. The less we rely on other libraries the better. :)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-pla
Op 2010-06-22 14:13, Michael Schnell het geskryf:
> The "Linux Way" is more like doing separate executable than doing
> threads, as Linux always provided high-performance inter process
> communication (e.g. pipes, usable with "select()" etc.) and process
> starting ( "fork()" ).
Form the previous
On Tue, 22 Jun 2010, Graeme Geldenhuys wrote:
Op 2010-06-22 14:24, Marco van de Voort het geskryf:
No, not straight away. That is technically impossible without integrating a
full C compiler, since POSIX requires to be able to read and interpret
And what if one implements a non-posix base
Op 2010-06-22 14:24, Marco van de Voort het geskryf:
>
> No, not straight away. That is technically impossible without integrating a
> full C compiler, since POSIX requires to be able to read and interpret
And what if one implements a non-posix based implementation (of Free
Pascal's own design)
On 22 June 2010 13:13, Michael Schnell wrote:
>
> Thus older Linux Kernels did not have special threading support.
> Threading could be done using "clone()" (instead of "fork()" ) to create
> processes that share some resources (e.g. memory). The kernel did not
Threading is still done with clone.
On 22 June 2010 13:24, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
>
>> Yes, but that would probably be a very daunting task.
>
> The problem is not the programming (since a dedicated person could probably
> start with a translated glibc in a good month), but the conti
In our previous episode, Henry Vermaak said:
> > If not, then I gather the C library (libc, glibc or whatever is used these
> > days) implemented threading in C code using the POSIX spec as the guide. So
> > couldn't one implement the POSIX spec (thinking of threading support only)
> > in pure Obje
On 06/22/2010 12:40 PM, Graeme Geldenhuys wrote:
> Just another question. Windows gets its threading support from the Win API.
> Similar for OS/2. Doesn't the Linux kernel have a similar threading API, or
> do they just rely on the C library?
>
The "Linux Way" is more like doing separate executa
1 - 100 of 103 matches
Mail list logo
