On Wed, Apr 17, 2024 at 12:42:42PM +0100, Daniel P. Berrangé wrote: > > This strategy fails completely if you have threads. In a thread > > (using a different stack entirely) it scans randomly across the heap, > > resulting in weird behaviour at best, but more usually straight > > crashes. > > Urgh, horrible. > > > > > We've had a Ruby plugin for a long time, but it broke with Ruby 1.9, > > when Ruby changed from some kind of cooperative threading to using > > native threads (and therefore separate stacks). > > > > The tests have been disabled since early 2018 (nbdkit < 1.2). I > > re-enabled the tests just now (Ruby 3.3) but it's broken in the same > > way as ever. > > > > The only changes that have happened since the tests were disabled are > > mechanical ones / project-wide cleanups. > > > > It currently crashes in open(). > > > > It seems highly unlikely that anyone is using this plugin. > > IIUC, the '--threads' arg is just a per-client limit. So if > there are multiple clients, you'll still get many threads > using ruby even with "--threads = 1".
If the plugin requests NBDKIT_THREAD_MODEL_SERIALIZE_REQUESTS, then --threads is ignored (see server/connections.c that forces nworkers to 0 if thread_model < NBDKIT_THREAD_MODEL_PARALLEL). But the Ruby plugin was already requesting NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS, and it is still broken, so this isn't helping. > > If spawning nbdkit with --single though, you'll get a separate > process per client, and then with --threads=1, you could can > sure that only 1 thread is calling into ruby. > > Is there a way a plugin can declare that it is non-threadsafe, > and thus allow nbdkit to refuse to run it without --single > and --threads=1, being set ? The thread_model interface should be usable for this, if we thought it was worth trying to keep Ruby alive in this limited use scenario. > > I guess that will complicate your test suite though unless > you can skip all tests which rely on multi-connections and > threads. Any test for multi-conn across all compiled plugins/filters should already be checking --help output to ensure whether the plugin supports parallel behavior and skip if not supported (if we decide that the Ruby plugin should advertise that it must run non-threaded, rather than just dropping it). -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org _______________________________________________ Libguestfs mailing list -- guestfs@lists.libguestfs.org To unsubscribe send an email to guestfs-le...@lists.libguestfs.org
