Re: Feasibility of using Ada in new development

[wojtek@power.com.pl (Wojtek Narczynski)]

Hello,

With ST implementations already exist. Non-preemptive scheduling (from
GHS) alone is not enough. What I would need is scheduling based on
file descriptor readiness.

> Fundamentally, what you need is fast task switching and and if you
> want to minimize the number of locks, non-preemptive scheduling.

This is why I asked about a cooperative GNAT runtime some time ago on
this list :-)

> I also think that it is possible to compile the FSU Pthreads library
> in such a way that it will give you non-preemptive scheduling. Whether
> the GNAT runtime would still work with a modified FSU pthreads, I
> cannot say.

I compiled GNAT 3.4.1 FSU pthreads runtime. When I use libgthread.a
supplied with binary gnat-3.15p it only grumbles about errno at link
time. When I export errno in my app, it works. I also compiled the
curent fsu pthreads http://www.informatik.hu-berlin.de/~mueller/pthreads/
(only compiles with gcc 2.x series), but those two turned out to be
rather out of sync, and it is not documented, which version of
pthreads, and which switches, to use.

But in general this is my current idea to obtain a runing cooperative
fsu-pthreads gnat 3.4.1 runtime, and then try to modify the scheduler
to consider IO. The problem is signals, my current idea is to have
minimal signal handlers that will merely make note of the signal
reception, and then have the scheduler dispatch the actual
Signal_Handler. I also expect to run into scalability problems of the
runtime itself, mean things like All_Task_List, with emphasis on
'list'. Another idea of mine is to port the runtime to GNU Pth, which
does the same as ST, and more. Porting the GNAT runtime to ST seems
infeasible.

> I would think using any library derived from Netscape *IS* high risk.
> It is easily the most bug-ridden program on my desktop.

You might be confusing Netscape server business (yes, there used to be
one), with their browser busines :-) Using State Threads incurrs
little risk alone, because it is only 3000 lines of (IMO quite good)
code, but using C is high risk. This is why, for quite some time, I've
been thinking how to do it in Ada.

> Also, do not believe that when using non-preemptive scheduling that
> you can get rid of *ALL* locks. Depending on you application, there
> will usually be locks which must be held between activations of your
> thread.

There sure will be locks, but they never require syscalls, nor even
CMPXCHG. In other words, they are extremely fast locks. But it's not
really about locks, it's about socket descriptor readiness.

Thanks for confirming what I already know on this subject :-)

Regards,
Wojtek