Cannot specify socket as blocking

[billygout]

The configuration for sockets support many options, but doesn't support specifying a socket as blocking or non-blocking. Suggest to add support for this as a new boolean field blocking.

". For example:

[socket:test]
host = 0.0.0.0
port = 8000
blocking = true

This creates a blocking socket on port 8000. If the parameter is absent, it will assume the value of "false", in keeping with the current default behaviour.

[coveralls]

Coverage decreased (-0.05%) to 62.809% when pulling 24090c7 on billygout:master into 5014c52 on circus-tent:master.

[k4nar]

Looks great!

However, I wonder if there is a reason for this not being an option. @billygout : Did you try circus with blocking sockets ?

[billygout]

Thanks for the quick response!

However, I wonder if there is a reason for this not being an option.

I also wonder if there's a reason for it not being an option :) Here are some potential reasons, I've come up with:

1. It's not strictly necessary since, even though the blocking/non-blocking property is passed on to the spawned processes, a spawned process can mark the fd as blocking/non-blocking post-fork, and that will affect only that particular child and not its siblings or parent. So, I could set the fd as blocking in my application and rebuild my binary application, but if one wants to support an old binary without modifying and rebuilding it, as in my case, the socket should be in the expected state at fork time.
2. Papa doesn't currently support the ability to configure its managed socket as blocking/non-blocking. I'm not even sure what the default is for papa...
3. Perhaps the blocking property should be associated with the watcher rather than the socket, and a watcher with the "blocking_sockets" property enabled would have the effect that all sockets are set to blocking/non-blocking while spawning that particular watchers processes. This could be handled in the preexec() func (https://github.com/circus-tent/circus/blob/master/circus/process.py#L269). I think choosing between keeping the property with the socket or the watcher should depend on whether a given socket is likely to be used by multiple watchers -- one wanting all its socket's to be blocking and the other wanting all its sockets to be non-blocking -- in which case, it would make sense to keep the property with the watcher. If, on the other hand, it's more likely that a watcher will want blocking or non-blocking behaviour on a per-socket basis, that would suggest it makes sense to keep the property with the socket.

Did you try circus with blocking sockets ?

Sure, I tried circus with blocking sockets. I added the "blocking" feature in order to support a fastcgi binary, based on application that I use which expects a blocking socket. The application blows up when the socket is non-blocking, since, the library I'm using, libfcgi, doesn't retry when EWOULDBLOCK is returned by accept() (https://github.com/toshic/libfcgi/blob/master/libfcgi/os_unix.c#L1175-L1179). Note that even the simple server example including in circus changes the socket to blocking (https://github.com/circus-tent/circus/blob/master/examples/simplesocket_server.py#L10-L12).

[k4nar]

Wow, thanks for sharing those info :) . I'm all for it then, and adding it to the socket options seems to be the best way.

However, I think that adding a small test case wouldn't hurt. I don't think it will be too hard. Also, could you update the doc?

[billygout]

I'll do my best with a test case and the doc. Thanks

On Thu, Apr 21, 2016 at 11:38 AM, Yannick PÉROUX notifications@github.com
wrote:

Wow, thanks for sharing those info :) . I'm all for it then, and adding it
to the socket options seems to be the best way.

However, I think that adding a small test case wouldn't hurt. I don't
think it will be too hard. Also, could you update the doc?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#973 (comment)

[billygout]

@k4nar Added doc and test

[coveralls]

Coverage decreased (-0.01%) to 62.842% when pulling e56bf94 on billygout:master into 5014c52 on circus-tent:master.

[k4nar]

Great, thanks!

[ChaoticMind]

Is this line doing anything? (also line133)

[billygout]

@ChaoticMind: Certainly not. Those two lines you mentioned were left over from my debugging. Feel free to clean it up. Thanks!