System calls - GNAT library vs. direct bindings

System calls - GNAT library vs. direct bindings

[Maciej Sobczak]

Hi,

I would like to now your opinion about the two options in the subject.

Let's suppose that the problem is a network-aware application on the
POSIX system. Ada doesn't know about network per RM, so we have to
look around for libraries.
One option is to use the GNAT library that has some package for
sockets.
Another is to write thin wrappers that bind directly to relevant
system calls (socket, connect, read, write, close, bind, listen,
accept, select - that's it for the basic stuff).

1. The advantage of using GNAT library is portability across various
systems that are targeted by GNAT. (I assume that the GNAT library is
available outside of POSIX - if not, please correct me.)

2. The advantage of writing custom thin wrappers is portability across
various compilers that target POSIX platforms.

The first is not really important for me, I will probably use only
POSIX systems.
The seconds is not important neither, I will probably use only GNAT.

In other words - the focus for evaluation should go elsewhere.
Performance? Maintainability? Some other factors?

Thank you for your feedback.

--
Maciej Sobczak
http://www.msobczak.com/

Re: System calls - GNAT library vs. direct bindings

[Ludovic Brenta]

Maciej Sobczak writes:
> Let's suppose that the problem is a network-aware application on the
> POSIX system. Ada doesn't know about network per RM, so we have to
> look around for libraries.
> One option is to use the GNAT library that has some package for
> sockets.
> Another is to write thin wrappers that bind directly to relevant
> system calls (socket, connect, read, write, close, bind, listen,
> accept, select - that's it for the basic stuff).

There is also adasockets: http://www.rfc1149.net/devel/adasockets

-- 
Ludovic Brenta.

Re: System calls - GNAT library vs. direct bindings

[Maciej Sobczak]

On 31 Maj, 17:06, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:

> There is also adasockets:http://www.rfc1149.net/devel/adasockets

The above link doesn't work.
Another link found on Google shows that this library is GPL - I'd
prefer something more free.

--
Maciej Sobczak
http://www.msobczak.com/

Re: System calls - GNAT library vs. direct bindings

[Ludovic Brenta]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 31 Maj, 17:06, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
>> There is also adasockets:http://www.rfc1149.net/devel/adasockets
>
> The above link doesn't work.
> Another link found on Google shows that this library is GPL - I'd
> prefer something more free.

Strange, we must be reading different pages:

http://www.rfc1149.net/devel/adasockets.html.en

"You can download the stable version (1.8.5) under a modified GPL
licence similar to the one held by GNAT. In particular, that means
that you can freely use AdaSockets in a proprietary application
without having it contaminate your code."

-- 
Ludovic Brenta.

Re: System calls - GNAT library vs. direct bindings

[Michael Bode]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> "You can download the stable version (1.8.5) under a modified GPL
> licence similar to the one held by GNAT. In particular, that means
> that you can freely use AdaSockets in a proprietary application
> without having it contaminate your code."

Am I the only one to think this formulation needs a little more
elaboration these days?

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: System calls - GNAT library vs. direct bindings

[Markus E Leypold]

> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>
>> "You can download the stable version (1.8.5) under a modified GPL
>> licence similar to the one held by GNAT. In particular, that means
>> that you can freely use AdaSockets in a proprietary application
>> without having it contaminate your code."
>
> Am I the only one to think this formulation needs a little more
> elaboration these days?

I'm not sure it really _needs_ elaboration, but mentioning the words
"linking exception" and perhaps calling the license GMGPL would (a)
help to emphasize the salient point and (b) encourage reading the
actual license / linking exception clause in question.

I think the formulation is quite clear as it is, if you look
thoroughly, but if you don't, it doesn't go to any extra effort to
point out the difference to GPL. 

Regards -- Markus

Re: System calls - GNAT library vs. direct bindings

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> In other words - the focus for evaluation should go elsewhere.
> Performance? Maintainability? Some other factors?

Our compiler is GNAT, and we develop and unit test on Windows, the
target is VxWorks on PowerPC.

We decided that GNAT.Sockets was perfectly OK for our needs (that
doesn't mean we think it's perfect) and that we had enough to do
developing our application without doing a socket library as well.

AdaSockets wasn't really an option given that GNAT already has a
library. It would have been yet another library to justify to the
technical authority.

Re: System calls - GNAT library vs. direct bindings

[Georg Bauhaus]

Simon Wright wrote:

> given that GNAT already has a
> library. It would have been yet another library to justify to the
> technical authority.

Are standards and portability still an issue in Ada projects?

Aonix seems to offer a standards conforming POSIX binding.
Can't say how much networking it offers.

Re: System calls - GNAT library vs. direct bindings

[Maciej Sobczak]

On 31 Maj, 22:07, Simon Wright <simon.j.wri...@mac.com> wrote:

> We decided that GNAT.Sockets was perfectly OK for our needs (that
> doesn't mean we think it's perfect)

Why is it not perfect?

--
Maciej Sobczak
http://www.msobczak.com/

Re: System calls - GNAT library vs. direct bindings

[anon]

In <1180623520.303981.191090@q75g2000hsh.googlegroups.com>, Maciej Sobczak <see.my.homepage@gmail.com> writes:
>Hi,
>
>I would like to now your opinion about the two options in the subject.
>
>Let's suppose that the problem is a network-aware application on the
>POSIX system. Ada doesn't know about network per RM, so we have to
>look around for libraries.
>One option is to use the GNAT library that has some package for
>sockets.
>Another is to write thin wrappers that bind directly to relevant
>system calls (socket, connect, read, write, close, bind, listen,
>accept, select - that's it for the basic stuff).
>
>1. The advantage of using GNAT library is portability across various
>systems that are targeted by GNAT. (I assume that the GNAT library is
>available outside of POSIX - if not, please correct me.)
>
>2. The advantage of writing custom thin wrappers is portability across
>various compilers that target POSIX platforms.
>
>The first is not really important for me, I will probably use only
>POSIX systems.

One factor is that Ada was designed for portability there if you do not care 
about portability then do not use Ada!

>The seconds is not important neither, I will probably use only GNAT.

Wrappers defeat the purpose of use Ada, so do not use them!

>
>In other words - the focus for evaluation should go elsewhere.
>Performance? Maintainability? Some other factors?


Performance -- use the OS's core language. Which normally means 
using C instead of writing code in Ada or using Wrappers.  But as the 
performance of the code goes up the maintainability starts to drop. 
This is due to the fact that performance alorithms are normally tied to 
the hardware and as hardware is update the alorithms may need to be 
rewritten just to maintain current performance levels which increases 
the maintainability cost.  

But portability gives an average stable performance with a reduced 
maintainability cost. Which means that development cost may be high but 
installation and maintains cost afterwards for the software team is very 
low. Especially in this age of upgrading the hardware every 6 to 18 months.
So unless one wants to spend the rest on the days updating and rewritting 
code to maintain that package, portability should be the highest priority.

Re: System calls - GNAT library vs. direct bindings

[Markus E Leypold]

> In <1180623520.303981.191090@q75g2000hsh.googlegroups.com>, Maciej Sobczak <see.my.homepage@gmail.com> writes:
>>Hi,
>>
>>I would like to now your opinion about the two options in the subject.
>>
>>Let's suppose that the problem is a network-aware application on the
>>POSIX system. Ada doesn't know about network per RM, so we have to
>>look around for libraries.
>>One option is to use the GNAT library that has some package for
>>sockets.
>>Another is to write thin wrappers that bind directly to relevant
>>system calls (socket, connect, read, write, close, bind, listen,
>>accept, select - that's it for the basic stuff).
>>
>>1. The advantage of using GNAT library is portability across various
>>systems that are targeted by GNAT. (I assume that the GNAT library is
>>available outside of POSIX - if not, please correct me.)
>>
>>2. The advantage of writing custom thin wrappers is portability across
>>various compilers that target POSIX platforms.
>>
>>The first is not really important for me, I will probably use only
>>POSIX systems.
>


> One factor is that Ada was designed for portability there if you do not care 
> about portability then do not use Ada!

What nonsense, Mr anon@anon.org. 

Since there is no portable library for reading any sensors, then your
kind of portability is gone as soon as there is a hardware specific
driver for sensors anywhere. By your definition, almost all real world
code is unportable.

The right way to achieve portability is, of course, to encapsule the
environment / target specific parts of your system into an abstract
layer (say, abstract over sockets towards a send_message_to_my_server
and recieve_message_from_my_server module). Then one has only port the
layer(s) that interface to the outside world, if the target changes.


<snipped>

> But portability gives an average stable performance with a reduced 
> maintainability cost. Which means that development cost may be high but 
> installation and maintains cost afterwards for the software team is very 
> low. Especially in this age of upgrading the hardware every 6 to 18 months.
> So unless one wants to spend the rest on the days updating and rewritting 
> code to maintain that package, portability should be the highest priority.

Astonishin argument. You know that you don't need to port software to
a higher cpu clock speed?


Regards -- Markus

Re: System calls - GNAT library vs. direct bindings

[Maciej Sobczak]

On 1 Cze, 08:59, a...@anon.org (anon) wrote:

> One factor is that Ada was designed for portability there if you do not care
> about portability then do not use Ada!

I don't understand. Does it mean that Ada is such a crap that if
portability is not an issue than the only things that remain in the
language are disadvantages?
What other language would you recommend then?

> Wrappers defeat the purpose of use Ada, so do not use them!

Most libraries for Ada are wrappers for something.

> Performance -- use the OS's core language.

Why should that be any different?
>From the point of view of client application, OS is just API. With
some calling convention. It doesn't really matter what is a "core
language" there, it might be even assembler.
The only thing that *does* matter is that to achieve ultimate
performance with OS' services, one usually needs direct access to this
API.

> But as the
> performance of the code goes up the maintainability starts to drop.

You must be coming from some strange place.

> This is due to the fact that performance alorithms are normally tied to
> the hardware and as hardware is update the alorithms may need to be
> rewritten just to maintain current performance levels which increases
> the maintainability cost.

Yes. You are coming from some strange place.

--
Maciej Sobczak
http://www.msobczak.com/

Re: System calls - GNAT library vs. direct bindings

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> 1. The advantage of using GNAT library is portability across various
> systems that are targeted by GNAT. (I assume that the GNAT library is
> available outside of POSIX - if not, please correct me.)
> 
> 2. The advantage of writing custom thin wrappers is portability across
> various compilers that target POSIX platforms.
> 
> The first is not really important for me, I will probably use only
> POSIX systems.
> The seconds is not important neither, I will probably use only GNAT.
> 
> In other words - the focus for evaluation should go elsewhere.
> Performance? Maintainability? Some other factors?

It's usually better to reuse something that has been widely used than to 
recreate the wheel. Reuse is generally less effort than creating a new 
library. An existing library is usually better tested and has fewer 
errors than a custom library. And an existing library's maintenance is 
generally not part of your project's maintenance effort, while a custom 
library's maintenance is.

Portability is generally a good thing, even if you don't think you need 
it. Many systems that were created under the assumption that portability 
wasn't an issue were later ported at greater effort than would have been 
involved in creating them to be portable in the 1st place.

To my mind, given the existence of a library that is portable across 
compilers and platforms, such a library should be used. In the absence 
of such a library, but given the existence of an existing library such 
as GNAT's, I'd probably choose the existing library, but would add a 
wrapper around it in case I need to use another compiler. Only in the 
absence of any existing libraries would I write my own, and I'd try to 
make it portable across compilers and platforms.

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers
49

Re: System calls - GNAT library vs. direct bindings

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 31 Maj, 22:07, Simon Wright <simon.j.wri...@mac.com> wrote:
>
>> We decided that GNAT.Sockets was perfectly OK for our needs (that
>> doesn't mean we think it's perfect)
>
> Why is it not perfect?

Because it was created by humans ...

Specifically, the behaviour with UDP streams is bizarre -- it all
looks as though the data is transferred correctly, but each atomic
data item is sent/received in a separate datagram.

The implementation of Socket_Type (and there's a naming issue straight
away!) suffers from not being controlled, and might be better
reference-counted (we've just had to deal with a file descriptor leak
caused by this).

I'm not sure that it was necessary to use 2 (3, temporarily) invisible
sockets in the implementation of Selectors (perhaps it is, haven't
thought about it deeply).

Re: System calls - GNAT library vs. direct bindings

[Simon Wright]

"Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org> writes:

> In the absence of such a library, but given the existence of an
> existing library such as GNAT's, I'd probably choose the existing
> library, but would add a wrapper around it in case I need to use
> another compiler.

I suppose that depends on the licence of the GNAT library and on
whether it depends on GNAT-specific features (pragmas, etc) in any
important way.

Re: System calls - GNAT library vs. direct bindings

[Simon Wright]

Georg Bauhaus <bauhaus.rm.tsoh@maps.futureapps.de> writes:

> Simon Wright wrote:
>
>> given that GNAT already has a
>> library. It would have been yet another library to justify to the
>> technical authority.
>
> Are standards and portability still an issue in Ada projects?

I think my masters are more interested in portability than in
standards. I know that adherence to standards should bring increased
portability; what to do about an RFP that requests 7-layer OSI
conformance?  AFAICR we decided that they weren't serious and offered
run-of-the-mill TCP/IP (BSD-style).

I don't see how AdaSockets is better than GNAT.Sockets in the sense of
conforming to standards? The web site talks about BSD sockets ...

> Aonix seems to offer a standards conforming POSIX binding.
> Can't say how much networking it offers.

Can't see what benefits this offers to anyone programming in Ada
(unless you need to tick off items in a compliance matrix). Convince
me, someone?

Re: System calls - GNAT library vs. direct bindings

[Pascal Obry]

anon a �crit :
> In <1180623520.303981.191090@q75g2000hsh.googlegroups.com>, Maciej Sobczak <see.my.homepage@gmail.com> writes:
>> Hi,
>>
>> I would like to now your opinion about the two options in the subject.
>>
>> Let's suppose that the problem is a network-aware application on the
>> POSIX system. Ada doesn't know about network per RM, so we have to
>> look around for libraries.
>> One option is to use the GNAT library that has some package for
>> sockets.
>> Another is to write thin wrappers that bind directly to relevant
>> system calls (socket, connect, read, write, close, bind, listen,
>> accept, select - that's it for the basic stuff).
>>
>> 1. The advantage of using GNAT library is portability across various
>> systems that are targeted by GNAT. (I assume that the GNAT library is
>> available outside of POSIX - if not, please correct me.)
>>
>> 2. The advantage of writing custom thin wrappers is portability across
>> various compilers that target POSIX platforms.
>>
>> The first is not really important for me, I will probably use only
>> POSIX systems.
> 
> One factor is that Ada was designed for portability there if you do not care 
> about portability then do not use Ada!
> 
>> The seconds is not important neither, I will probably use only GNAT.
> 
> Wrappers defeat the purpose of use Ada, so do not use them!
> 
>> In other words - the focus for evaluation should go elsewhere.
>> Performance? Maintainability? Some other factors?
> 
> 
> Performance -- use the OS's core language. Which normally means 
> using C instead of writing code in Ada or using Wrappers.  But as the 
> performance of the code goes up the maintainability starts to drop. 
> This is due to the fact that performance alorithms are normally tied to 
> the hardware and as hardware is update the alorithms may need to be 
> rewritten just to maintain current performance levels which increases 
> the maintainability cost.

That's nonsense! An intern project comparing the "same" application
built with OpenMP/C++ and Ada shows that we have the same level of
performances. Ada is slightly better in fact. This is not one-to-one
kind of comparison as we wanted to use both technology as it should. So
in OpenMP/C++ we have parallel loops on the Ada side we have designed a
pipeline of tasks. The Ada architecture is then higher level, but gives
slightly better performances.

I'm fighting days after days the idea than low-level gives better
performances. This is just plain wrong. It has probably be true at some
point with tailored assembly applications. This is just not possible
those days as processors are so complex than only a compiler can
schedule the instruction properly. So no, C based languages, as
low-level as they seems, are not necessary faster.

Today discussion was about the C ternary operator being faster than a
standard if. The gain is three CPU cycles (well that's what the guy was
arguing). Who cares ? Especially when the algorithm is just a mess of
non optimal code :( How often people get swamped by low-level stuff
amaze me !

Now please this is ONE bench. It just shows that at least low level does
not necessary means faster, that's all. I have not said that Ada is
always faster right :)

Last but not least Mister Anon, it is polite on the Net to sign messages.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: System calls - GNAT library vs. direct bindings

[Pascal Obry]

Sorry for the large quote I thought I had removed all but the last
quoted paragraph :(

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: System calls - GNAT library vs. direct bindings

[Maciej Sobczak]

On 1 Cze, 19:42, "Jeffrey R. Carter"
<spam.jrcarter....@acm.nospam.org> wrote:

> It's usually better to reuse something that has been widely used than to
> recreate the wheel. Reuse is generally less effort than creating a new
> library.

That's right.

> Portability is generally a good thing, even if you don't think you need
> it.

Please note that I was talking about targetting POSIX systems.
That *is* thinking about portability!

> To my mind, given the existence of a library that is portable across
> compilers and platforms, such a library should be used.

Yes. The point is - GNAT library is not compiler-agnostic.

> In the absence
> of such a library, but given the existence of an existing library such
> as GNAT's, I'd probably choose the existing library,

Yes, but...

> but would add a
> wrapper around it

Bingo. And calling system API directly also requires a wrapper - at
least for convenience. Interestingly, for funcions as simple as read/
write/listen/etc., both wrappers will have comparable complexity.
Note that no matter how the wrapper is written, it isolates two
parties and as such can be later used to achieve freedom from both
compiler and system.

So we are really comparing writing two wrappers. Same effort with same
effect.

--
Maciej Sobczak
http://www.msobczak.com/

Re: System calls - GNAT library vs. direct bindings

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> Bingo. And calling system API directly also requires a wrapper - at
> least for convenience. Interestingly, for funcions as simple as read/
> write/listen/etc., both wrappers will have comparable complexity.
> Note that no matter how the wrapper is written, it isolates two
> parties and as such can be later used to achieve freedom from both
> compiler and system.

IIRC, you were talking about a thin binding. To my mind, at least, a 
thin binding is not comparable to a portable wrapper. Depending on 
circumstances, a thin binding can sometimes be a single package spec 
with some pragma-Import subprograms (probably not in this case). Many 
difficult issues are left to the client.

More importantly, a binding, thin or otherwise, has to deal with the 
vagaries of interfacing to C, and is more difficult to get right than a 
wrapper around an Ada library, which is simply Ada calling Ada.

-- 
Jeff Carter
"Propose to an Englishman any principle, or any instrument, however
admirable, and you will observe that the whole effort of the English
mind is directed to find a difficulty, a defect, or an impossibility
in it. If you speak to him of a machine for peeling a potato, he will
pronounce it impossible: if you peel a potato with it before his eyes,
he will declare it useless, because it will not slice a pineapple."
Charles Babbage
92