From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,adb9b9207aecb4b3 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.freenet.de!news.tu-darmstadt.de!news.belwue.de!news.uni-stuttgart.de!carbon.eu.sun.com!new-usenet.uk.sun.com!not-for-mail From: Ole-Hjalmar Kristensen Newsgroups: comp.lang.ada Subject: Re: epoll Ada binding Date: 21 Oct 2004 10:23:30 +0200 Organization: Sun Microsystems Message-ID: References: <311c6b78.0410181100.76f4e8ab@posting.google.com> <311c6b78.0410182103.110885b7@posting.google.com> NNTP-Posting-Host: khepri06.norway.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: new-usenet.uk.sun.com 1098347012 10359 129.159.112.195 (21 Oct 2004 08:23:32 GMT) X-Complaints-To: usenet@new-usenet.uk.sun.com NNTP-Posting-Date: 21 Oct 2004 08:23:32 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:5566 Date: 2004-10-21T08:23:32+00:00 List-Id: >>>>> "ML" == Mark Lorenzen writes: ML> Wojtek Narczynski writes: >> Hello, >> >> > It would be very impressive if you succeed in making an efficient >> > task-based implementation with 10000 concurrent connections. >> >> The first step is to create a lightweight userspace tasking runtime, then >> make the scheduler IO aware. First I tried to rewrite FSU threads in Ada, >> function by function, structure by structure. Currently I perceive it as >> truly moronic. After having taken a good look at OpenRavenscar and Jose >> Tasking Kernel, I think I am on the right track. I have a lot of >> functionality working. One humongous missing piece is signals / >> interrupts. After all that making the scheduler IO aware will be a piece >> of cake. ML> OK, so it requires a special run-time system. If the tasks are I/O ML> aware, will the "usual" Ada task behaviour be preserved? ML> For some time I have been thinking how to make a library, which can be ML> used for the purpose of building networking applications. But instead ML> of patching the run-time system, I was thinking of a library which ML> could provide Ada equivalents for SDLs process and service ML> constructs. When providing a process set, the library user could ML> choose to have a process set where each process was a co-procedure ML> (i.e. one task handles many connections) or choose to have a process ML> set where each process was a task (i.e. one task handles one ML> connection). The choice could be mde by instantiating from different ML> packages or inheriting from different classes. But wouldn't it be better if the built-in tasks could be made lightweight enough by changing the run time system? Then you would not have to choose between two different task types, and all your familiar abstractions would work. Actually I miss Occam on the transputers, where task switching had the same cost as a subroutine call. ML> If this library also could provide a general way of implementing state ML> machines (a tagged type for each state?), it would provide powerful ML> infrastructure for networking applications. I think this is better handled by a program generator, like this one: http://smc.sourceforge.net >> >> The #1 obstacle is my regular job ;-) >> >> Thanks for the reassurance that my thinking is sound, I need it... >> >> Regards, >> Wojtek ML> - Mark Lorenzen -- C++: The power, elegance and simplicity of a hand grenade.