<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Once upon a time, on 11/16/2012 01:19
PM to be precise, Jonas Maebe said:<br>
</div>
<blockquote
cite="mid:A2395645-7B5B-403C-B190-31B2AA337AFB@elis.ugent.be"
type="cite">Cthreads initialzes the thread manager record by
explicitly assigning the thread manager record fields, not by
declaring a typed constant. That means the compiler does not check
for uninitialized fields. It seems this routine indeed still needs
to be implemented for Unix platforms.<br>
</blockquote>
Right, I see. I've reported a bug on this matter.<br>
<br>
<br>
<br>
<blockquote
cite="mid:A2395645-7B5B-403C-B190-31B2AA337AFB@elis.ugent.be"
type="cite">
<blockquote type="cite"> - On Mac Os X 10.6.8 the compiler
complains about the fact that my
<br>
equivalent of the Function CBeginThread is incompatible with
the one
<br>
in the TThreadManager Record (The result types are
incompatible,
<br>
aswell as the type of ThreadId: Pointer [Linux; this is also
what is
<br>
typed in the source file] <> TThreadId [Mac OS X]).
This is very
<br>
strange 'cause I copied the declaration of every function
over from
<br>
CThreads.pp. Should be the same, no?
<br>
</blockquote>
<br>
If you also use the same units in your interface as cthreads, yes.<br>
</blockquote>
Well, the compiler gives this error:<br>
`Incompatible types: got <br>
"<address of
function(Pointer,QWord,TThreadFunc,Pointer,LongWord,var <b>
Pointer</b>):^<b>untyped</b>;Register>" expected<br>
"<procedure variable type of
function(Pointer,QWord,TThreadFunc,Pointer,LongWord,var <b>
TThreadID</b>):^<b>TThreadRec</b>;Register>"<br>
`<br>
<br>
Rather weird, no? Have I missed something? Or is this due to the
fact that I declare my threadmanager record using a typed constant?<br>
<br>
Note: Th compiler also complains about several other
functions/procedures involving the tpe TThreadID. Same error as the
one above.<br>
<br>
<br>
<br>
<blockquote
cite="mid:A2395645-7B5B-403C-B190-31B2AA337AFB@elis.ugent.be"
type="cite">
<blockquote type="cite"> - Declaration of `pthread_key_create`
differs from Mac OS X to
<br>
linux? Very weird because the documentation for both OS'es
says
<br>
exactly the same, which is basically this:
<br>
<br>
`Type TCProcedure = Procedure(arg: Pointer); cdecl;
<br>
<br>
Function pthread_key_create(key: ppthread_key_t;
DestructorFunc:
<br>
TCProcedure): cint; cdecl; external name
'pthread_key_create';`
<br>
</blockquote>
<br>
What difference do you mean exactly?
<br>
Linux: pthread_key_create : Function(__key:ppthread_key_t;
__destr_function:__destr_function_t):longint;cdecl;
<br>
Mac OS X: function pthread_key_create (p : ppthread_key_t;f:
__destr_func_t):cint; cdecl;external 'c';
<br>
</blockquote>
Well, I discovered that some code was contained in an $ifdef block,
while it shouldn't. So there is indeed no difference between the two
calls. Sorry for that.<br>
<br>
<br>
<br>
<blockquote
cite="mid:A2395645-7B5B-403C-B190-31B2AA337AFB@elis.ugent.be"
type="cite">
<blockquote type="cite">Then some things that seem unlogical to
me:
<br>
<br>
- `Procedure IntbasiceventSetEvent` contains a Try...Finally
block,
<br>
while there is no code inbetween that could possibly raise an
<br>
exception. Why is it there? (are some signals "converted" to
an
<br>
exception? If so, why isn't this in almost every other
function as
<br>
well?)
<br>
</blockquote>
<br>
That was added by the person who did the very first
implementation. There were in fact more try/finally's in the
original implementation, but those have already been removed in
the mean time. This one was apparently missed.<br>
</blockquote>
I see. I've also reported a bug on this one.<br>
<br>
<br>
<br>
<blockquote
cite="mid:A2395645-7B5B-403C-B190-31B2AA337AFB@elis.ugent.be"
type="cite">
<blockquote type="cite"> - Parameters `creationFlags` and `sa`
in CBeginThread of CThreads.pp
<br>
appear to be unused?
<br>
</blockquote>
<br>
They are only used on Windows currently (they correspond to the
corresponding arguments of the Windows CreateThread API). We
should probably add a check for nil/0 and give an error if they
are different on Unix.
<br>
</blockquote>
Yep, as I said, I'm not into windows programming lately. So it
basically has no meaning at all on non-windows OS'es?<br>
<br>
<br>
<blockquote
cite="mid:A2395645-7B5B-403C-B190-31B2AA337AFB@elis.ugent.be"
type="cite">Removing recursive mutex support would completely
break Windows/Delphi/past-FPC compatibility for critical sections,
so that is definitely not going to happen. At best, we can give an
error when creating the critical section if no recursive mutex
support is available.<br>
</blockquote>
Right, I didn't know this. The best solution would be, as you said,
to give an error in case no recursive mutex support is available.<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:A2395645-7B5B-403C-B190-31B2AA337AFB@elis.ugent.be"
type="cite">
<blockquote type="cite"> - The types of TRTLCriticalSection and
TThreadID are not defined in
<br>
the same unit as the thread manager, which means that
creating
<br>
custom implementations of these (especially true for critical
<br>
sections) is impossible. As an example: suppose I want to use
an
<br>
integer for busy waiting as a critical section, I would
define
<br>
TRTLCriticalSection as an integer. Now I am stuck with
pthreads'
<br>
mutex, which is not handy if you want to do this kinda thing
with an
<br>
integer.
<br>
</blockquote>
<br>
They are indeed defined according to the OS thread interface. If
necessary, I guess we could change them all to pointers, although
it would probably break a lot of code though (since currently,
code can use variables of those types with native OS thread
functions).</blockquote>
Indeed it would perhaps break to much code to do any good,
especially true for TThreadID. Then again there are `eassier` types,
for example TRTLCriticalSection, which never gets used as a
parameter in a system call... Or am I wrong in saying that?<br>
<br>
<blockquote
cite="mid:A2395645-7B5B-403C-B190-31B2AA337AFB@elis.ugent.be"
type="cite">It's not true that that the current type differences
mean that a custom implementation is impossible though, although
it will require some typecasting in your manager.</blockquote>
Yep, that's what I did to give it a try, and of course it works, but
it is, let's admit it, a rather hackish way and a waste of good
memory. Also it doesn't really give you code that compiler
everywhere. So in my opinion it can be called `Impossible`.<br>
<br>
<blockquote
cite="mid:A2395645-7B5B-403C-B190-31B2AA337AFB@elis.ugent.be"
type="cite">You can also add a check like this to your code to
ensure that you don't make wrong assumptions:
<br>
<br>
{$if sizeof(tthreadid) < sizeof(longint)}
<br>
{$error tthreadid must be at least the size of a longint for this
thread manager to function correctly}
<br>
{$endif}
<br>
</blockquote>
This is very interesting to generate `safer` code (i.e. only perform
the typecast when there is enough memory), but it still doesn't give
one a clean solution.<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:A2395645-7B5B-403C-B190-31B2AA337AFB@elis.ugent.be"
type="cite">
<blockquote type="cite">And something I haven't yet investigated
thoroughly:
<br>
<br>
- On Max OS X, `sem_open` appears not to be found. This might
be a
<br>
simply typo of mine, but maybe there's someone with the same
problem?
<br>
</blockquote>
<br>
Where is it not found/how are you looking for it? Or are you
perhaps confusing it with sem_init, which indeed does not exist on
Mac OS X?
<br>
<br>
</blockquote>
No, it's definetly sem_open, the litteral error is:<br>
`Error: Identifier not found "sem_open"`<br>
<br>
My uses list contains the exact same units as in CThreads.pp, in the
same order, so I don't see why the symbol isn't found. Also, the
entire load of $idfdef's are also copied into my source code.<br>
<br>
Undeffing `has_sem_open` makes the code compile.<br>
<br>
Same goes for `SEM_FAILED`, but this is related to the very same
issue I believe.<br>
<br>
<pre class="moz-signature" cols="72">--
Ewald
</pre>
</body>
</html>