Displaying 3 results from an estimated 3 matches for "serialize_retir".
2020 Aug 10
1
Re: [nbdkit PATCH 2/3] server: Expose final thread_model to filter's .get_ready
...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.
> 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 order; for
> filters, exposing a new threading model through .get_ready is not a
> problem (all filters are in tree), but for plugin...
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
...fication 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 order; for filters, exposing a new threading
model through .get_ready is not a problem (all filters are in tree), but
for plugins, such an actio...