> 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 needed. Back-ends which follow it would just be used like now (result:=...) while those which differ would be "translated" (eg: if ... <> xxx then Result:=-1) As I said it's far from perfect, but it gives a consistent interface atleast. Ales 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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel