Re: [dev] [st] possibly redundant check in techo

2014-08-14 Thread Steven Degutis
> What processador do you use in your port? intel or ibm? I'm on OS X 10.9 on an Intel Mac Pro, using LLVM + Clang. > There was a discussion in this list sometime ago about this > topic, and I think this was the best solution (if someone can > find the messages ...), but I agree that if char is s

Re: [dev] [st] possibly redundant check in techo

2014-08-14 Thread Roberto E. Vargas Caballero
On Thu, Aug 14, 2014 at 04:38:24PM -0500, Steven Degutis wrote: > Convenience link to the line: http://git.suckless.org/st/tree/st.c#n2315 > > Here, techo is calling ISCONTROL(c) where c is a 'char'. But > ISCONTROLC1 is always going to return false for a char. This is not true, char can be signe

[dev] [st] possibly redundant check in techo

2014-08-14 Thread Steven Degutis
Convenience link to the line: http://git.suckless.org/st/tree/st.c#n2315 Here, techo is calling ISCONTROL(c) where c is a 'char'. But ISCONTROLC1 is always going to return false for a char. Perhaps it should test against ISCONTROLC0 instead? Or is this line intended to use ISCONTROL for some reas

Re: [dev] [abduco] Read-only connect to session from other user

2014-08-14 Thread Marc André Tanner
On Thu, Aug 14, 2014 at 07:16:55PM +, Ben Golding wrote: > As you pointed out, '-ar' behaves as '-a', connecting in read-write mode > without any warning. Using '-a -r' connects in read-only mode. Yes I might change the command line parsing code to also accept the former. > > > As the other u

RE: [dev] [abduco] Read-only connect to session from other user

2014-08-14 Thread Ben Golding
Hi Marc, Indeed, changing the socket perms to 777 does allow the other user to connect. As you pointed out, '-ar' behaves as '-a', connecting in read-write mode without any warning. Using '-a -r' connects in read-only mode. So now someone has tried it :) > > As the other user, I run 'abduco -ar

Re: [dev] [abduco] Read-only connect to session from other user

2014-08-14 Thread Marc André Tanner
Hi, Sorry for the late reply, I'm currently busy with exams and a proof of concept for a text editor. > I just switched from dtach to abduco, so that I could try to share a > session (view-only) with another user. > Is that expected to work? I have never tried it but in principle it should. > I

Re: [dev] [quark] Current performance and ideas

2014-08-14 Thread FRIGN
On Thu, 14 Aug 2014 10:35:23 +0100 Dimitris Papastamos wrote: > Must be some other BSD because iirc OpenBSD doesn't have sendfile. > I think FreeBSD does though. Ah, my bad. It was freebsd[0]. [0]: http://www.freebsd.org/cgi/man.cgi?query=sendfile&sektion=2 -- FRIGN

Re: [dev] [quark] Current performance and ideas

2014-08-14 Thread Dimitris Papastamos
On Thu, Aug 14, 2014 at 10:57:50AM +0200, FRIGN wrote: > ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count); > int sendfile(int fd, int s, off_t offset, size_t nbytes, > struct sf_hdtr *hdtr, off_t *sbytes, int flags); > > And this is just Linux and OpenBSD.

Re: [dev] [quark] Current performance and ideas

2014-08-14 Thread Dimitris Papastamos
On Thu, Aug 14, 2014 at 10:57:50AM +0200, FRIGN wrote: > On Thu, 14 Aug 2014 09:35:07 +0100 > Dimitris Papastamos wrote: > > Hey Dimitris, > > thanks for the patches you sent in earlier! > > > Obviously these numbers do not mean anything unless compared to > > some other http server implementat

Re: [dev] [quark] Current performance and ideas

2014-08-14 Thread FRIGN
On Thu, 14 Aug 2014 09:52:44 +0100 Dimitris Papastamos wrote: > One thing that needs to be fixed in the current model > is to timeout existing connections that we have received no > data from in a time interval. > > So consider the following: > > for i in $(seq 1 1000); do > nc 127.0.0.1

Re: [dev] [quark] Current performance and ideas

2014-08-14 Thread FRIGN
On Thu, 14 Aug 2014 09:35:07 +0100 Dimitris Papastamos wrote: Hey Dimitris, thanks for the patches you sent in earlier! > Obviously these numbers do not mean anything unless compared to > some other http server implementation. > > From some quick testing that me and Hiltjo did yesterday, we fo

Re: [dev] [quark] Current performance and ideas

2014-08-14 Thread Dimitris Papastamos
One thing that needs to be fixed in the current model is to timeout existing connections that we have received no data from in a time interval. So consider the following: for i in $(seq 1 1000); do nc 127.0.0.1 & done This will create 1000 processes on the server, all of them blocked on

[dev] [quark] Current performance and ideas

2014-08-14 Thread Dimitris Papastamos
Hi all, I've used wrk[0] to benchmark quark over a loopback interface. With the latest code in git we have: $ ./wrk -t1 -c200 -d30s http://127.0.0.1 Running 30s test @ http://127.0.0.1 1 threads and 200 connections Thread Stats Avg Stdev Max +/- Stdev Latency 4.5