[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gawk] Adding an API hook to enable a select extension

From: Andrew J. Schorr
Subject: Re: [bug-gawk] Adding an API hook to enable a select extension
Date: Fri, 31 May 2013 14:59:40 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Eli,

On Fri, May 31, 2013 at 09:48:09PM +0300, Eli Zaretskii wrote:
> It doesn't have to.  The implementation of that loop could relinquish
> CPU while the program waits.  There shouldn't even be a call to
> 'sleep' on the Awk program's level, that detail should be hidden under
> the hood.  For example, we could have a new looping command, to be
> used instead of 'while', which is suited for such event loops.

I have already agreed that somebody may want to implement a higher-level
event dispatching construct.  So there's no argument here.  But I'm
not going to implement it.

> IOW, if the Awk programmer wants an event loop, she should just say
> so, and Gawk will DTRT.  Let's not ask the programmer to program all
> that explicitly.  Because if we do, we will next need to tell them to
> handle interrupted system calls, signals, and whatnot.  If I need to
> do all that, I'd rather code it all in C.

That's a reasonable opinion.  Others may feel differently.

> Awk is not a system programming language.  It is higher-level, so it
> should conceal such details from the programmer.  Like it does with
> memory allocation, for example.  IMO, at least.

I know of at least one awk program I've written where a select command
would have been useful.  I am merely proposing to extend the API to
enable the creation of extension libraries that can provide a low-level
select capability or a higher-level event dispatch framework.  Either
way, the same gawk API hook will be needed.

There are three issues here:

1. Should the gawk API be extended so that extension libraries can retrieve
file descriptors?  This will allow 

2. Should a "select" extension library be included in the main gawk
distribution?  If it is not wanted in gawk for some reason, I am happy
to put it in gawkextlib.

3. Should core gawk getline be enhanced to handle non-blocking I/O properly?
In other words, should we detect EAGAIN/EWOULDBLOCK and allow further
I/O to the file after such an error?  This both makes the READ_TIMEOUT
feature work better and helps to ensure that non-blocking I/O can
be multiplexed without danger of getting stuck.

The whole point of the extension mechanism is to enable people to build the
tools that they need.  If you don't like select, you are free not to use it.
And you don't have to worry about destroying the beauty of the AWK language,
since this feature will not be inside gawk itself.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]