Re: Suggestion: Lua 5.3 -- a facility for creating and manipulting Lua file handles (C API)

[Sean Conner <sean@...>]

It was thus said that the Great Sir Pogsalot once stated:
> 1) Well yes :]  I had seen this:
> http://w3.impa.br/~diego/software/luasocket/tcp.html#receive
> 
> I was trying to find a list of errors that it might throw back at me?  I
> swear I must be missing it somewhere... halp?

  Not even the Unix man pages list all the possible errors.  For instance,
open(2) reports the following errors:

	EACCES	EEXIST	EFAULT	EFBIG	EINTR	EISDIR	ELOOP	EMFILE 
	ENFILE	ENODEV	ENOENT	ENOMEM	ENOSPC	ENOTDIR	ENXIO	EOVERFLOW
	EPERM	EROFSETXTBSY	EWOULDBLOCK	ENAMETOOLONG

  Fine, until you are opening a file under NFS and suddenly you find
yourself also receiving ETIMEDOUT.  

  Also, there's not much a program can do in the face of some of the errors,
and what you can do depends upon the context of the program (say, a daemon
opening a configuration file and gets back ELOOP---there isn't much the
daemon can do except exit; a word processor, on the other hand, can ask the
user for a different filename).

  Short of expecting some errors (say, getting ENOENT, but in context that's
okay because it means there's no data saved from a previous run) there isn't
much more you can do that log the error using strerror() (in my opinion,
having done this type of thing for over twenty years).

> 3) Linux has a lovely getaddrinfo_a() that does lookups in parallel... you
> could start multiple worker threads with something like lua-lanes to do
> individual getaddrinfo()'s but that's a lot of responsibility/liability on
> you... I wish getaddrinfo_a() were portable XD

  Which distribution of Linux?  I tried four different Linux distributions
and none of them had getaddrinfo_a().  

> 4) Okay, maybe I only wanted to break abstractions for using different
> polling interfaces/APIs.  :getfd() was hard, lol.  (j/k)  The more I dug
> into the source for luasocket the more I wanted to create my own binding.
>  I think what Diego did is great, but there's a lot of code in there done
> for efficiency (he has his own buffer object).  I try tried to write as
> little as possible so as to avoid introducing my own unexpected behavior --
> but I'm not implying luasocket isn't well-written.  I just wanted to use
> what was already there like luaL_Buffer to copy out from recv() and such.

  The standard IO buffering routines really only work for TCP connections;
sure, you can use them for UDP sockets, but you really need to set the
buffering to none (in C, setvbuf(fp,NULL,_IONBF,0) and in Lua,
fp:setvbuf('none')) for them to work properly, but even then, you need
connected sockets for that to work well, and in a UDP based server, that's a
hard thing to really pull off [1].

  -spc

[1]	There is no accept() call for UDP.  No, what you need to use is
	recvfrom() or recvmsg() which gives you the remote address to reply
	to; it also gives you data, so there goes reading it via the
	standard C IO library.

	Of course, GCC allows you to extend the standard C IO library, but
	that's the issue---it's a GCC extension; if you aren't using GCC,
	you can't do that.