Here's a revised version that should be pretty close to done, except
for needing libasyncns and less logging. Blocking on getaddrinfo
doesn't concern me too much for the initial release, given that
primary use of this should be with localhost IPs.
If this gets a thumbs-up, I'll send in a proper
On Mon, Oct 14, 2013 at 3:53 AM, David Strauss da...@davidstrauss.net wrote:
Here's a revised version that should be pretty close to done
And also aside from my Unix socket and IPv6 TODOs, which are tiny.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
Slightly better performance now with per-connection buffers.
[root@olympian systemd]# ab -n1000 -c10 http://localhost:8080/
This is ApacheBench, Version 2.3 $Revision: 1430300 $
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation,
On Thu, Oct 10, 2013 at 10:12 PM, Tollef Fog Heen tfh...@err.no wrote:
I'd go with something how it's done in Varnish: Have an (or n)
acceptor threads that schedule work to a pool of worker threads. That
scheduler should be careful about such things as treating the worker
threads as LIFO (to
On Thu, Oct 10, 2013 at 09:54:12PM -0700, David Strauss wrote:
Here's a first take on having sabridge use the systemd-native event
library. The current, full diff is also visible on GitHub [1].
Obviously, this work still needs considerable cleanup and tightening.
I like how we're currently
On Fri, 11.10.13 07:12, Tollef Fog Heen (tfh...@err.no) wrote:
]] Lennart Poettering
On Thu, 10.10.13 13:12, David Strauss (da...@davidstrauss.net) wrote:
I was actually planning to rewrite on top of libuv today, but I'm
happy to port to the new, native event library.
Is
On Thu, 10.10.13 21:54, David Strauss (da...@davidstrauss.net) wrote:
#define __STDC_FORMAT_MACROS
This is an unnecessary C++ism, isn't it?
#include errno.h
#include stdio.h
#include stdlib.h
#include string.h
#include netdb.h
#include sys/fcntl.h
#include sys/socket.h
#include
On Tue, 08.10.13 02:07, David Strauss (da...@davidstrauss.net) wrote:
I've attached the initial implementation -- not yet ready to merge --
for an event-oriented socket activation bridge. It performs well under
load. I haven't tied up all potential leaks yet, but the normal
execution paths
On Tue, 08.10.13 13:12, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Tue, Oct 08, 2013 at 02:07:27AM -0700, David Strauss wrote:
I've attached the initial implementation -- not yet ready to merge --
for an event-oriented socket activation bridge. It performs well under
load.
On Thu, Oct 10, 2013 at 05:08:26PM +0200, Lennart Poettering wrote:
On Tue, 08.10.13 13:12, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Tue, Oct 08, 2013 at 02:07:27AM -0700, David Strauss wrote:
I've attached the initial implementation -- not yet ready to merge --
for
On Thu, 10.10.13 17:39, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Thu, Oct 10, 2013 at 05:08:26PM +0200, Lennart Poettering wrote:
On Tue, 08.10.13 13:12, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
wrote:
On Tue, Oct 08, 2013 at 02:07:27AM -0700, David
On Thu, Oct 10, 2013 at 8:39 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
One thing which we can't make work currently, is having the target
service managed by systemd, but running with PrivateNetwork=yes. In
this case, the bridge process must be inside of the target service
and
I was actually planning to rewrite on top of libuv today, but I'm
happy to port to the new, native event library.
Is there any best-practice for using it with multiple threads?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
On Thu, Oct 10, 2013 at 01:12:26PM -0700, David Strauss wrote:
I was actually planning to rewrite on top of libuv today, but I'm
happy to port to the new, native event library.
Is there any best-practice for using it with multiple threads?
Best-practice is using just one thread :)
Zbyszek
On Thu, Oct 10, 2013 at 1:20 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
Best-practice is using just one thread :)
That depends on whether you need to scale up to multiple cores.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
On Thu, 10.10.13 13:12, David Strauss (da...@davidstrauss.net) wrote:
I was actually planning to rewrite on top of libuv today, but I'm
happy to port to the new, native event library.
Is there any best-practice for using it with multiple threads?
We are pretty conservative on threads so
On Thu, Oct 10, 2013 at 7:07 PM, Lennart Poettering
lenn...@poettering.net wrote:
All load balancing would be done by the kernel,
and that's kinda cool, because they actually are good at these things...
This is essentially what I was advocating a while back for other
event-oriented frameworks
Here's a first take on having sabridge use the systemd-native event
library. The current, full diff is also visible on GitHub [1].
Obviously, this work still needs considerable cleanup and tightening.
I like how we're currently hammering out the basics, like the event
library to use and where the
]] Lennart Poettering
On Thu, 10.10.13 13:12, David Strauss (da...@davidstrauss.net) wrote:
I was actually planning to rewrite on top of libuv today, but I'm
happy to port to the new, native event library.
Is there any best-practice for using it with multiple threads?
We are
I've attached the initial implementation -- not yet ready to merge --
for an event-oriented socket activation bridge. It performs well under
load. I haven't tied up all potential leaks yet, but the normal
execution paths seem to be clean. I also need to use proper shell
option management.
The
On Tue, Oct 08, 2013 at 02:07:27AM -0700, David Strauss wrote:
I've attached the initial implementation -- not yet ready to merge --
for an event-oriented socket activation bridge. It performs well under
load. I haven't tied up all potential leaks yet, but the normal
execution paths seem to be
On Tue, Oct 8, 2013 at 4:12 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
how do you intend target service to be started? I understand that the
intended use case case is for non-socket-activatable services, so they
should be started synchronously in the background. In case of local
I should also mention that the way I've integrated libev in the
autotools chain makes it optional. If you don't have it, you just
won't get the bridge utility.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
On Tue, Oct 8, 2013 at 4:56 AM, David Strauss da...@davidstrauss.net wrote:
There's no reason it couldn't scale to any number in future versions.
Sorry for the copious replies, but I have another thing to add here.
The current design doesn't rely on globals; it passes all state up the
stack in
El 08/10/13 08:56, David Strauss escribió:
(2) Waits for nginx's PID file
hold on there, are you aware that almost no software available creates
this pid files in a race-free fashion ?
--
If debugging is the process of removing bugs, then programming must be
the process of putting them in.
The bridge won't relay traffic until it gets a connection. This is also no
worse than the situation with other systemd services.
On Oct 8, 2013 3:28 PM, Cristian Rodríguez crrodrig...@opensuse.org
wrote:
El 08/10/13 08:56, David Strauss escribió:
(2) Waits for nginx's PID file
hold on
26 matches
Mail list logo
