> if I understand you correctly, you are saying that your implementation of these
> primitives is non-preemptive
yes,
> but it does call some primitives in the Pthreads library, yes?
yes - but these low level primitives are non-preemptive and do not
invoke the Pthread scheduler. The low level GNU Pthread primitives
used by SYSTEM.mod are very similar to TRANSFER and NEWPROCESS.
(pth_uctx_create, pth_uctx_make, pth_uctx_save, pth_uctx_switch).
http://www.gnu.org/software/pth/pth-manual.html
Ok, I see we have had a misunderstanding.
You are not in fact using Pthreads, you are using Pth.
This is the library I mentioned, which has a POSIX compatible API and which was once used to create a non-preempted Apache server.
I suspect the overhead of using the functions: pth_uctx_create,
pth_uctx_make, pth_uctx_save, pth_uctx_switch is pretty small (a few
function call overheads at most).
It seems reasonable to assume that the set of primitives you are using will have significantly less overhead than the overhead associated with using Pth as a drop in replacement for a Pthreads based software, such as the non-preempted Apache server I had mentioned. Yet, it would be interesting to do some benchmarks against LibTask and see how these two stack up against each other.
all interesting stuff. [ It justifies the Plan 9 design - avoid
threads and make fork/exec efficient - but I digress..]
:-)
There are quite a few scholars who have extensive expertise in this field who have come to the conclusion that preemptive threads are evil. The link I had provided in a previous post links to several such scholastic papers.
I venture to speculate, but not without reason, that even if you manage to get fork/exec as efficient as kernel threads, it still isn't going to be anywhere near as efficient as coroutines, aka actors, aka user level threads.
> I don't have a link at hand but I have come across reports with performance
> data by Ericsson which showed that telecommunication switches with
> non-preemptive scheduling systems can have scalability advantages of several
> orders of magnitude over preemptive ones. Our own experiments with software
> switched telephone calls confirms this.
very interesting, I'd be interesting to read these reports.
Like I said, I don't have any links at hand now, but I remember to have stumbled into several performance reports when researching Erlang. I believe that a web search for "Erlang" and "telecommunications", possibly "Ericsson" should be a good start to find those.
As for our own experiments, past experience has shown that the folks whose software didn't do well in scalability benchmarks can be very hostile against critics and so I will refrain from posting results in public, at least until our R&D has reached a stage where we have non-experimental code to release so that independent parties can verify whatever claims we will make then. However, I am going to send you a mail directly with some further details.
a while ago I wrote a small micro-kernel for work all
serial link. Thus I have a vested interest in ensuring that it will
support cross compilation and embedded systems. On a minor note gm2
has been build as a cross compiler for the ATMega8 microprocessor,
albeit coroutines were not used on this chip,
Very interesting.
Let us know when you are going to do some coroutine work on an embedded platform ;-)