[fpc-devel]promised tthread patch
johannes at sipsolutions.com
Sun Nov 16 19:36:29 CET 2003
On Sat, 2003-11-15 at 04:52, KJK::Hyperion wrote:
> not arbitrary. The rules are roughly the same as those for signaling
> (SuspendThread, in Windows, is implemented with a kernel-mode signal, like
> most system calls targeting threads). The only problem I see is the
> interaction with waits - but, on the other hand, EINTR has been banned from
> POSIX threads as cumbersome and of limited usefulness, and all POSIX
> threading interfaces restart interrupted waits automatically
Thats nice. However, I need to patch fpSleep(), it uses some _WEIRD_
code to block signals and stuff -- it never ever sleeps for me! Haven't
taken a look at it yet, used fpnanosleep for the time being.
> true. A crude and rude interface. But not supporting it at all?
Well, I'm all for supporting it from within threads, in a nice way. Btw,
forget my second part of writing in the patch (about the warning), its
not really possible, I was thinking .suspend should never be called but
its ok from within a thread!
Anyway, I'm trying to think of a way to suspend a thread (maybe force a
signal to be handled by that thread and then suspend somehow from the
sighandler, I don't know how though, probably not possible). If anyone
things of something I'm ok with adding it, but I want a _clean_ solution
for suspending from within the thread itself.
GnuPG key: http://www.sipsolutions.de/keys/JohannesBerg.asc
Key-ID: 9AB78CA5 Johannes Berg <johannes at sipsolutions.de>
Fingerprint = AD02 0176 4E29 C137 1DF6 08D2 FC44 CF86 9AB7 8CA5
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 194 bytes
Desc: This is a digitally signed message part
More information about the fpc-devel