almindor at gmail.com
Wed Nov 8 21:19:33 CET 2006
> Just define an opaque type TThreadResult:
> TThreadResult = DWord // Windows
> TThreadResult = cInt // Unices
I don't like this solution for several reasons:
1. What if one OS has more backends for threading available, which
differ in this?
2. How are we going to handle error states on cross-platform
TThreadManager using code?
Ofcourse, in a perfect world I'd come up with something nice by now
myself.. well surprise surprise I haven't.
I don't think there's a 100% clean solution but IMHO we should pick one
internal scheme and go with it. For example say we choose to use a
signed integer, -1 for error and specific values for specific situations
Back-ends which follow it would just be used like now (result:=...)
while those which differ would be "translated" (eg: if ... <> xxx then
As I said it's far from perfect, but it gives a consistent interface
P.S: I do realize that there might be functions which result value
returns eg: something which needs to be taken and passed along, or which
value is variable (not constant). In case we abstract the return value,
we limit this, so I say we abstract it to something BIG
More information about the fpc-devel