Re: Non-blocking socket bug
On Sat, Oct 26, 2019 at 09:42:47PM +0100, Sad Clouds wrote: > On Sat, 26 Oct 2019 15:20:42 -0500 > Edgar Pettijohn wrote: > > > > > On Oct 26, 2019 2:44 PM, Sad Clouds > > wrote: > > > > > > I've come across an issue when testing networking code, which looks > > > like a bug. This is on NetBSD-8.1 > > > > > > When a listening socket is set non-blocking and we call accept() on > > > that socket, the new socket returned by accept() will also be > > > non-blocking. > > > > > > I think this is a bug. I thought all new sockets/file descriptors > > > would be non-blocking by default. I've attached a test program to > > > demonstrate the issue. > > > > That is how the manual describes it to be. > > Can you be more specific please, which manual and which case does it > describe, accept() returning blocking or non-blocking socket? > > I'm not sure at this stage if this is a bug or BSD specific feature. http://man.openbsd.org/NetBSD-8.1/accept The accept() argument extracts the first connection request on the queue of pending connections, creates a new socket with the same properties of s and allocates a new file descriptor for the socket. Same properties being the key concept here I believe. Edgar
Re: Non-blocking socket bug
On Oct 26, 2019 2:44 PM, Sad Clouds wrote: > > I've come across an issue when testing networking code, which looks > like a bug. This is on NetBSD-8.1 > > When a listening socket is set non-blocking and we call accept() on > that socket, the new socket returned by accept() will also be > non-blocking. > > I think this is a bug. I thought all new sockets/file descriptors would > be non-blocking by default. I've attached a test program to demonstrate > the issue. That is how the manual describes it to be. > > On Linux: > $ ./a.out > Create server thread > Create client thread > Accept connection, fd=5, addr=127.0.0.1, port=47746 > Connected socket is blocking > > On NetBSD: > $ ./a.out > Create server thread > Create client thread > Accept connection, fd=5, addr=127.0.0.1, port=65534 > Connected socket is non-blocking > > Any ideas or comments? > > Thanks.
Re: Non-blocking socket bug
On Sat, 26 Oct 2019 17:07:16 -0400 g...@duzan.org wrote: > 2.10.7 Socket I/O Mode > The I/O mode of a socket is described by the O_NONBLOCK file status > flag which pertains to the open file description for the socket. This > flag is initially off when a socket is created, but may be set and > cleared by the use of the F_SETFL command of the fcntl() function. > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/accept.html OK thanks for the links, so looks like a NetBSD bug then. I created kern/54650 PR.
Re: Non-blocking socket bug
=> On Sat, 26 Oct 2019 15:20:42 -0500 => Edgar Pettijohn wrote: => =>> =>> On Oct 26, 2019 2:44 PM, Sad Clouds =>> wrote: =>> > =>> > I've come across an issue when testing networking code, which looks =>> > like a bug. This is on NetBSD-8.1 =>> > =>> > When a listening socket is set non-blocking and we call accept() on =>> > that socket, the new socket returned by accept() will also be =>> > non-blocking. =>> > =>> > I think this is a bug. I thought all new sockets/file descriptors =>> > would be non-blocking by default. I've attached a test program to =>> > demonstrate the issue. =>> =>> That is how the manual describes it to be. => => Can you be more specific please, which manual and which case does it => describe, accept() returning blocking or non-blocking socket? => => I'm not sure at this stage if this is a bug or BSD specific feature. => https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_10_07 2.10.7 Socket I/O Mode The I/O mode of a socket is described by the O_NONBLOCK file status flag which pertains to the open file description for the socket. This flag is initially off when a socket is created, but may be set and cleared by the use of the F_SETFL command of the fcntl() function. https://pubs.opengroup.org/onlinepubs/9699919799/functions/accept.html DESCRIPTION The accept() function shall extract the first connection on the queue of pending connections, create a new socket with the same socket type protocol and address family as the specified socket, and allocate a new file descriptor for that socket. So accept() creates a socket, and O_NONBLOCK is initially off when a socket is created, so it should be off. Gary Duzan
Re: Non-blocking socket bug
On Sat, 26 Oct 2019 15:20:42 -0500 Edgar Pettijohn wrote: > > On Oct 26, 2019 2:44 PM, Sad Clouds > wrote: > > > > I've come across an issue when testing networking code, which looks > > like a bug. This is on NetBSD-8.1 > > > > When a listening socket is set non-blocking and we call accept() on > > that socket, the new socket returned by accept() will also be > > non-blocking. > > > > I think this is a bug. I thought all new sockets/file descriptors > > would be non-blocking by default. I've attached a test program to > > demonstrate the issue. > > That is how the manual describes it to be. Can you be more specific please, which manual and which case does it describe, accept() returning blocking or non-blocking socket? I'm not sure at this stage if this is a bug or BSD specific feature.
Non-blocking socket bug
I've come across an issue when testing networking code, which looks
like a bug. This is on NetBSD-8.1
When a listening socket is set non-blocking and we call accept() on
that socket, the new socket returned by accept() will also be
non-blocking.
I think this is a bug. I thought all new sockets/file descriptors would
be non-blocking by default. I've attached a test program to demonstrate
the issue.
On Linux:
$ ./a.out
Create server thread
Create client thread
Accept connection, fd=5, addr=127.0.0.1, port=47746
Connected socket is blocking
On NetBSD:
$ ./a.out
Create server thread
Create client thread
Accept connection, fd=5, addr=127.0.0.1, port=65534
Connected socket is non-blocking
Any ideas or comments?
Thanks.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define ADDR "127.0.0.1"
#define PORT
/* Set fd blocking or non-blocking */
void set_fd_nonblock(int fd, bool set_flag)
{
int ret_int, fcntl_flags;
/* Get current flags */
fcntl_flags = fcntl(fd, F_GETFL, 0);
if (fcntl_flags == -1)
{
fprintf(stderr, "Error %s:%d: fcntl() with F_GETFL failed, %s\n",
__FILE__, __LINE__, strerror(errno));
exit(EXIT_FAILURE);
}
if (set_flag)
{
/* Set non-blocking */
fcntl_flags |= O_NONBLOCK;
}
else
{
/* Set blocking */
fcntl_flags &= ~O_NONBLOCK;
}
ret_int = fcntl(fd, F_SETFL, fcntl_flags);
if (ret_int == -1)
{
fprintf(stderr, "Error %s:%d: fcntl() with F_SETFL failed, %s\n",
__FILE__, __LINE__, strerror(errno));
exit(EXIT_FAILURE);
}
}
/* Check fd is non-blocking */
bool is_fd_nonblock(int fd)
{
int fcntl_flags;
/* Get current flags */
fcntl_flags = fcntl(fd, F_GETFL, 0);
if (fcntl_flags == -1)
{
fprintf(stderr, "Error %s:%d: fcntl() with F_GETFL failed, %s\n",
__FILE__, __LINE__, strerror(errno));
exit(EXIT_FAILURE);
}
return (fcntl_flags & O_NONBLOCK);
}
/* Client thread */
static void *cli(void *arg)
{
struct sockaddr_in addr;
int conn_fd;
memset(&addr, 0, sizeof(addr));
if (inet_pton(AF_INET, ADDR, &(addr.sin_addr)) != 1)
{
fprintf(stderr, "Error %s:%d: inet_pton() failed, %s\n", __FILE__, __LINE__, strerror(errno));
exit(EXIT_FAILURE);
}
addr.sin_family = AF_INET;
addr.sin_port = htons(PORT);
conn_fd = socket(AF_INET, SOCK_STREAM, 0);
if (conn_fd < 0)
{
fprintf(stderr, "Error %s:%d: socket() failed, %s\n", __FILE__, __LINE__, strerror(errno));
exit(EXIT_FAILURE);
}
if (connect(conn_fd, (struct sockaddr *)&addr, sizeof(addr)) != 0)
{
fprintf(stderr, "Error %s:%d: connect() failed, %s\n", __FILE__, __LINE__, strerror(errno));
exit(EXIT_FAILURE);
}
return NULL;
}
/* Server thread */
static void *srv(void *arg)
{
struct sockaddr_in addr, cli_addr;
socklen_t cli_addr_len;
char addr_str[INET6_ADDRSTRLEN];
int ret_int, listen_fd, conn_fd;
ssize_t ret_ssize;
struct pollfd pollfd_array[1];
memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl(INADDR_ANY);
addr.sin_port = htons(PORT);
/* The usual - socket, bind, listen */
listen_fd = socket(AF_INET, SOCK_STREAM, 0);
if (listen_fd < 0)
{
fprintf(stderr, "Error %s:%d: socket() failed, %s\n", __FILE__, __LINE__, strerror(errno));
exit(EXIT_FAILURE);
}
if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0)
{
fprintf(stderr, "Error %s:%d: bind() failed, %s\n", __FILE__, __LINE__, strerror(errno));
exit(EXIT_FAILURE);
}
if (listen(listen_fd, 128) < 0)
{
fprintf(stderr, "Error %s:%d: listen() failed, %s\n", __FILE__, __LINE__, strerror(errno));
exit(EXIT_FAILURE);
}
/* Set listening socket non-blocking */
set_fd_nonblock(listen_fd, true);
/* Set poll events */
pollfd_array[0].fd = listen_fd;
pollfd_array[0].events = (POLLIN | POLLRDNORM | POLLRDBAND | POLLPRI);
/* Block in poll until socket is ready for I/O */
ret_int = poll(pollfd_array, 1, -1);
if (ret_int < 0)
{
fprintf(stderr, "Error %s:%d: poll() failed, %s\n", __FILE__, __LINE__, strerror(errno));
exit(EXIT_FAILURE);
}
/* Accept new connection */
cli_addr_len = sizeof(cli_addr);
conn_fd = accept(listen_fd, (struct sockaddr *)&cli_addr, &cli_addr_len);
if (conn_fd < 0)
{
fprintf(stderr, "Error %s:%d: accept() failed, %s\n", __FILE__, __LINE__, strerror(errno));
exit(EXIT_FAILURE);
}
if (inet_ntop(AF_INET, &(cli_addr.sin_addr), addr_str, sizeof(addr_str)) == NULL)
{
fprintf(stderr, "Error %s:%d: inet_ntop() failed, %s\n", __FILE__, __LINE__, strerror(errno));
exit(EXIT_FAILURE);
}
fprintf(stdout, "Accept connection, fd=%d, addr=%s, port=%hu\n",
conn_fd, addr_str, ntohs(cli_addr.sin_port));
/* Check if connected socket is non-blocking or blocking */
if (is_fd_nonblock(conn_fd))
{
fprintf(stdout, "Connected socket is non-blocking\n");
}
else
{
fprintf(stdout, "Connected socket is blocking\n");
}
return NULL;
}
int main(void)
{
int ret_int;
pthread_t cli_tid, srv_tid;
fprintf(stdout, "Create server threa
Re: Lightweight GUI code editor
Hello, On Sat, 26 Oct 2019 17:51:29 +0200 Rocky Hotas wrote: > Hi all :)! > I am using NetBSD 8.1 with Openbox as Window Manager. While I usually > try to avoid GUI applications, because they include some bloat, I am > looking for a lightweight code editor: it should highlight the language > keywords (now I'm using Python, but the editor should support some other > common languages) and the corresponding parentheses, nothing more. > For example, the Atom editor would be perfect, but it is only available > on Linux. > Using nvi(1) for the same purpose is not as comfortable as I was > expecting. > Looking in > > https://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/editors/README.html > > I found many editors which I would try, but they are not available in my > 8.1 (2019Q3) repository, like `beaver', `codelite', `codeblocks', > `scite'. > Do you have any suggestion? I'm using joe for text mode and bluefish in X. Bluefish is supposedly made for web development but it supports all sorts of languages with a filesystem tree in a side panel, which is extremely useful when working on kernel code. Both do syntax highlighting and all sorts of other stuff. have fun Michael
Lightweight GUI code editor
Hi all :)! I am using NetBSD 8.1 with Openbox as Window Manager. While I usually try to avoid GUI applications, because they include some bloat, I am looking for a lightweight code editor: it should highlight the language keywords (now I'm using Python, but the editor should support some other common languages) and the corresponding parentheses, nothing more. For example, the Atom editor would be perfect, but it is only available on Linux. Using nvi(1) for the same purpose is not as comfortable as I was expecting. Looking in https://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/editors/README.html I found many editors which I would try, but they are not available in my 8.1 (2019Q3) repository, like `beaver', `codelite', `codeblocks', `scite'. Do you have any suggestion? Thank you anyway! Rocky
