Re: lynx-dev lynx+openssl

[Eldon Mellaney]

Hello.

New to the Lynx mailing list, but I thought I could add something ...

When a system call is made, e.g., connect(...), the operation may be carried
out in one of two ways.

When an application requests something from the operating system (which is
the resource manager) using a system call, e.g., establish a TCP connection
using connect(), control is passed to the operation system so that it can
handle the request.

A system call, e.g., connect(), is said to be blocking if the application
which has made the request of the operating system will wait indefinitely
for an answer from the operating system. In such cases, the application is
said to be "blocked" while it waits for a response (either positive or
negative) from the operating system.

If on the other hand, the application programmer has explicitly told the
operating system that the application is unwilling, or unable, to wait
indefinitely for an answer, but still wishes the operating system to attempt
to carry out the request, e.g., establish a TCP connection, then the system
call is said to be "non-blocking". In such cases, control is passed to the
operating system long enough for it to determine if it can carry out the
request _immediately_. If it cannot, the operating system immediately passes
control back to the application.

In the "non-blocking" case, the application programmer must handle the case
when a request for a resource cannot be completed immediately and control is
passed back to the application. One obvious, but very flawed, approach that
the programmer may take is to have the application attempt indefinitely to
acquire the resource it wants. This is called "busy waiting" and is very
wasteful of precious system resources, e.g., CPU cycles are spent changing
control from the operating system to the application program and back again
(called "context switching").

In the case below, the connect() system was non-blocking. The operating
system attempted to establish the TCP connection, but could not do so when
the request was made. Control was first passed to the operating system so
that it could determine whether the request could be carried out. Next, once
the operating system determined it could not carry out the request, it
immediately responding by returing a value to the application that made the
connect() system call. The value returned, i.e., return value of connect(),
indicates that the request to establish a TCP connection was not successful.
As a result, the program must now decide how to proceed: attempt again, but
attempt no more than N times (and hopefully with some delay between
attempts! Perhaps an exponential back-off algorithm that produces longer
delays with each failure.) or to quit trying because the host you are trying
to reach at the specified TCP port is unavailable. (Examine the return value
of connect() to see the reason for failure.) In the specific example below,
it appears that the first call to connect() failed (and the return value was
set to 115 to indicate the cause), but that a subsequent call to connect()
(would appear to be the second attempt) succeeded as the message "Operation
now in progress" was written to standard output.


Hope this proves useful.

Eldon.

p.s. I have studied operating systems formally, so the response is likely
much more than you want.

----- Original Message -----
From: Mike Bledig <address@hidden>
To: David Woolley <address@hidden>; <address@hidden>
Sent: Tuesday, January 25, 2000 3:51 PM
Subject: Re: lynx-dev lynx+openssl


> From:           David Woolley <address@hidden>
> On Mon, 24 Jan 2000 08:14:43 +0000 (GMT)
>
> > > > TCP: Error 115 in `SOCKET_ERRNO' after call to this socket's first
> > > > connect() failed.
> > > >       Operation now in progress
> >
> > This is not an error, it means that you are making a non-blocking
> > CONNECT call.
> >
>
> What is ment by that discription? can you explain to those of us
> who don't know?
>
>