Displaying 3 results from an estimated 3 matches for "nbdkit_final_thread_model".
2020 Aug 10
2
Re: [nbdkit PATCH 2/3] server: Expose final thread_model to filter's .get_ready
On Fri, Aug 07, 2020 at 05:00:52PM -0500, Eric Blake wrote:
> The next patch wants to add a filter that will prevent DoS attacks
> from a plaintext client; to be successful, the filter must guarantee
> that nbdkit did not settle on SERIALIZE_CONNECTIONS. The easiest way
> to solve this is to expose the final thread model to .get_ready, which
> is after the point where
2020 Aug 10
0
Re: [nbdkit PATCH 2/3] server: Expose final thread_model to filter's .get_ready
...be a good idea to add
> this to TODO.
We might as well, so I'll tweak TODO. But at the moment, I'm having a
hard time coming up with a justification for why any existing v2 plugin
would need to know this information, so without a client, I'm reluctant
to introduce a plugin-only nbdkit_final_thread_model() just to be
deprecated when v3 comes out.
Oh, one other oddity: I've been thinking about adding a fifth threading
model (SERIALIZE_RETIREMENT), where commands can be serviced in parallel
on a single connection, but replies to the client are reordered to match
the client's submission o...
2020 Aug 10
1
Re: [nbdkit PATCH 2/3] server: Expose final thread_model to filter's .get_ready
...; >this to TODO.
>
> We might as well, so I'll tweak TODO. But at the moment, I'm having
> a hard time coming up with a justification for why any existing v2
> plugin would need to know this information, so without a client, I'm
> reluctant to introduce a plugin-only nbdkit_final_thread_model()
> just to be deprecated when v3 comes out.
It's certainly hard to imagine why a plugin would worry about things
being more serialized than they requested, but OTOH it does make the
filter and plugin APIs consistent (w.r.t. the informational parameters
they both receive) which is nice.
&g...