On 20/04/17 10:22, Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:> > They are not really threads. They must be
scheduled within threads.> >
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682661(v=vs.85).aspx> > from the article
they don't seem to have that many advantages, except toconvert existing manual m:n scheduling apps.>
> Which effectively makes them coroutines, but since they're MS-only > they're nonportable.
What exactly makes them coroutines? Maybe that they implement a local
stackconcept.
Yes, exactly. Which I think is an abstraction that FPC doesn't have.
Even Turbo Pascal interrupt handlers worked within the same stack, as
distinct from TopSpeed's IOTRANSFER() which switched.
But you still would have to integrate that with FPC (exceptionhandling, stack
checking), so at the basic level it only saves some asmswitching contexts.
It's interesting that coroutines (Modula-2, perhaps others) precede
exceptions etc. (C++?). It might turn out that in practice they /have/
to be implemented first, otherwise the amount of doctrine that grows up
around exceptions makes the job implausible.
But maybe the OS support for stack switching makes things like keeping
SEHworking easier. (not that that is enabled by default for 32-bit windows x86)
Which is more or less where Ryan started off the > other thread.
It suddenly occured to me that that piece of code is compatible to nothingin
FPC, since the only likely target in FPC (win32 x86) doesn't use SEH.There is a
define to enable it though ( -dTEST_WIN32_SEH )
I think I said at the time that he should be looking at (an equivalent
of) fibers.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
