Michael Van Canneyt wrote:
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
We don't need the full-blown Win32 API for threads, nor do we need the
complete pthreads.
Agreed.
We need something portable.
Of course pthreads could be used as a source of ideas, So a partial
implementation of something rather compatible to pthreads would be nice.
-Michael
___
>
> 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 requir
On 27 nov 2006, at 15:46, Aleš Katona wrote:
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?
I can't find any such functions in unix/cthreads.pp (nor in the
system-dependent pthread include files), nor in
> > 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. Be
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" ar
> 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
http://lists.freepascal
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 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.
Th
> 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 :)
>
On 27 nov 2006, at 14:01, Jonas Maebe wrote:
I really think this does not matter in any way. Afaik the routines
which are affected all only return error codes, not values. So what
is really needed is a set of FPC-defined error codes, and
translations from the OS-specific error codes to the
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 no
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
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
fi
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 prop
>
> 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 re
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
http://lists.freepascal.org/m
> 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 whol
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
19 matches
Mail list logo
