The thing is full of this. Problem is, each OS and platform has slightly
different arguments and return types AND we need to be flexible enough
to support more than one threading implementation on same platform too
(so no godamn ifdefs).
use INT64 everywhere?
On Sun, 26 Nov 2006, C Western wrote:
Does the syncobjs unit in the FCL need to be machine dependent any more? The
functionality seems to be in the thread manager for all the platforms that
have threads, and I had some problems using the unit. (TRTLCriticalSection is
defined in sybcobjs and
Does the patch work for you ? If so, I'll apply it to FCL. It was planned to
do something similar, since when syncobjs was implemented, the TThreadManager
did not yet exist. Now that it does exist, syncobjs can be implemented on top
of it.
It might be perhaps better to wait until the whole
It might be perhaps better to wait until the whole ThreadManager problem
is solved one way or the other.
What exactly is the ThreadManager problem ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
What exactly is the ThreadManager problem ?
There are type differences in return types and arguments of many
functions. For example, ThreadManager.SuspendThread returns DWord in all
OSes and platforms (64bit 32bit) but eg: in cthreads we use:
Result := pthread_kill()..
pthread_kill
If you got a nice idea come up with it coz I'm kind of lost.
First thing that comes into my mind:
Use a TP-specific propriety integer value as a result and store the OS
specific value in an OS specific property so that it can be checked if
the user really needs to.
The OS specific
One solution is basicly to use a TThreadID kind of thing for all
arguments and return types. The problems with this are:
1. if one OS has multiple threading backends with multiple types, what
then? (ifdef isn't enough here)
2. who is going to check all platforms all usages of ThreadManager and
Aleš Katona schrieb:
One solution is basicly to use a TThreadID kind of thing for all
arguments and return types. The problems with this are:
1. if one OS has multiple threading backends with multiple types, what
then? (ifdef isn't enough here)
2. who is going to check all platforms all
On 27 nov 2006, at 13:56, Florian Klaempfl wrote:
Another solution is to use one big-enough type. But one day big-
enough
isn't going to be big enough and it still has problem #2.
It can be increased, but 128 bit is at least (128-64) bit/0.5 bit/
year away :)
I really think this does not
On 27 nov 2006, at 13:56, Florian Klaempfl wrote:
Another solution is to use one big-enough type. But one day big-
enough
isn't going to be big enough and it still has problem #2.
It can be increased, but 128 bit is at least (128-64) bit/0.5 bit/
year away :)
I really think
I also think this is the right way. If you specify OS specific return codes
per threadmanager, this will lead to unnecssary breakage.
Return codes are one thing, argument another. What are we going to do
about those? Eg: see ExitCode argument. It's a dword but int is
expected as well.
These
On 27 nov 2006, at 15:18, Aleš Katona wrote:
I also think this is the right way. If you specify OS specific
return codes
per threadmanager, this will lead to unnecssary breakage.
Return codes are one thing, argument another. What are we going to do
about those? Eg: see ExitCode argument.
I'd use a pointer, ptrint or ptruint in those cases. They naturally
grow with the cpu bitsize.
Sure and when it's a size_t expected?
Perhaps we should use unions..
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Mon, 27 Nov 2006, Aleš Katona wrote:
I also think this is the right way. If you specify OS specific return codes
per threadmanager, this will lead to unnecssary breakage.
Return codes are one thing, argument another. What are we going to do
about those? Eg: see ExitCode argument.
I'd use a pointer, ptrint or ptruint in those cases. They naturally
grow with the cpu bitsize.
Sure and when it's a size_t expected?
Perhaps we should use unions..
I wouldn't try to cater to each eventuality and possible problem. Just make
sure the main problems are covered. Better
I can't find any such functions in unix/cthreads.pp (nor in the
system-dependent pthread include files), nor in win/systhrd.inc
Who knows, perhaps syllable has such :) Point was, I think we should try
to make threading more future proof this time.
I'll try to make a list of required
Does the syncobjs unit in the FCL need to be machine dependent any more?
The functionality seems to be in the thread manager for all the
platforms that have threads, and I had some problems using the unit.
(TRTLCriticalSection is defined in sybcobjs and as part of the system
thread stuff). The
17 matches
Mail list logo
