Re: Ada The Best Language?

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

Ted Dennison wrote:
> 
> In article <3B586C51.53C17E25@home.com>, Warren W. Gay VE3WWG says...
> >
> >Hee, hee, but what are you going to do when you want to do a select(2) call
> >on a dozen file descriptors? Java doesn't give you a clean way to do this,
> >short of creating a dozen threads to each block on one descriptor. Or..
> >you can use non-blocking (gak) calls. Java still falls short in a number
> >of places. Ada of course, would not prevent you from calling select(2) or
> >poll(2). To do it in Java, requires the use of native methods, which would
> >be oh so ugly (creation of a shared library etc. etc.)
> 
> That's funny. This very much resembles a conversation I had Friday with an
> anti-Ada C user. Although Ada's on the other side this time, I feel honor bound
> to make the same points here that I did there.
> 
> 1) I don't see why it is such a bad thing to make a system call from Java, and
> not a bad thing to make the exact same system call from Ada. I realise that this
> may reduce Java's portability, but only down to the level at which your putative
> Ada example already exists. Your Ada (or Java) might be less portable for other
> reasons. But then those should be addressed, not this issue.

My point was primarily these two points:

  1. to do native calls in Java requires you to create a shared library, install
     that library, establish environment if necessary (SHLIB_PATH/LD_LIBRARY_PATH)
     etc. Conversely, with Ada, you simply insert pragma import, then link-- no
     muss, no fuss.

  2. The other point was that creating extra threads might be considered a heavy
     handed solution to the problem (depending upon application). I know someone
     who has had to deal with this very problem, and bemoans the lack of select/poll
     support.
     
And of course, there is the whole DOS scenario, which someone else covered.

> 2) Even though either language can do it just fine, I don't think "select"
> support is that big of a deal anyway. Most serious network servers (according to
> the literature I read) don't use select. They instead keep a pool of threads
> (tasks), and assign IP connections as they come in to the next available thread.
> Using "select" would tie up your entire server into processing one request at a
> time, which might be OK for something that doesn't get hit a lot, but would be
> horrible for a server that may expect several simultanious requests from
> different parties. "select" probably has its uses, but it seems to mostly be a
> holdover from the pre-thread era.

Failing native calls to select/poll, Java forces you to use one thread for
each socket/fd that you are waiting for events on. What may be a better approach
for some server designs, is a pool of threads (yes), but not as many as you have
fd/sockets for. Once an event has been registered for any of many many file
descriptors (from select say), you can then pass the "job" onto one of your
waiting server threads. This allows you to tune the resource requirements of
your server.

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg