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 attached patch shows what I had in mind - delete all the syncobjs.pp files in the platform directories.

Colin

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.

Michael.

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 ThreadManager problem is solved one way or the other. No matter which solution is chosen it's API is going to change.

No idea when someone's going to step up to it tho.

Ales

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

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 returns an int.

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).

If you got a nice idea come up with it coz I'm kind of lost.

Ales

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 property might be
- an OS specific type
- just some thing big enough (int64) so that it can be typecasted as necessary or
- there could by multiple of those properties with different types

Is this silly ?

-Michael

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 fix them? Who is going to test this.

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.

In any case it's going to hurt.

People will cry if things break, that's how OSS works.

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 :)

Example: the transition from 32 bit to 64 bit filepos and size wasn't even noticed by anybody :)

In any case it's going to hurt.

Well, it sounds complicated but usually it isn't that bad. If TThreadID isn't enough, indroduce a new type like TThreadKillResult. For multiple thread manager on the same target use the biggest type approach.

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 these FPC error codes.

Whether these FPC error codes are signed or not doesn't matter, and by the time people need more than 2**32 individual error code conditions regarding why a mutex (un)lock failed they'll need automatic ways to deal with that anyway.

Jonas

Initially, this could even simply be "no error" and "error occurred".

Jonas

I also think this is the right way. If you specify OS specific return codes per threadmanager, this will lead to unnecssary breakage.

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 can't be internaly abstracted like error codes.

I'd use a pointer, ptrint or ptruint in those cases. They naturally grow with the cpu bitsize.

Jonas

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 make a few exceptions/hacks here and there, then have a system that requires a 4 weeks course to handle.

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 win/systhrd.inc

Jonas

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 arguments and return types between platforms.

Ales

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

Take the lowest common denominator.

I think you're seeking too much problems. Just implement an interface that is workable on all OS-es, and can be used to implement TThread and syncobjs.

We don't need the full-blown Win32 API for threads, nor do we need the complete pthreads.

Michael.

I can confirm in works for me fine on Linux - I have not tested it on any other platform. There seems very little in the syncobjs unit, and what there is seems to be duplicated in the Threadmanager, so it seems to be easier to maintain with this patch.
Colin

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?