(and seems like a nice feature for everyone to have)
and if not, what differences do you see between the features in Jamoma (as presented in http://www.jamoma.org/publications/attachments/jamoma-icmc2006.pdf) and the current libossia ?
hummmmm
not sure there ever was a paper on libossia proper indeed
@jcelerier I wonder how you suggest that one uses multiplex protocol? I see that a device moves a unique pointer into it, you can get a reference of the protocol from the device but its type is erased..
I've hacked around it by grabbing a raw pointer before moving the protocol in the device, which works for adding.. but removing doesn't seem to be thread safe (something I mentioned a long time ago and am now revisiting)
https://github.com/Cycling74/libossia/blob/d7bbc9658d5ccfbb1f7eb3072a9bb6e87c5e98b9/tests/Network/MultiplexTest.cpp#L143-L227
this segfaults when pushing a value and removing a protocol at the same time.. I wasn't expecting to need a mutex on updating parameters
I've hacked around it by grabbing a raw pointer before moving the protocol in the device, which works for adding.. but removing doesn't seem to be thread safe (something I mentioned a long time ago and am now revisiting)
https://github.com/Cycling74/libossia/blob/d7bbc9658d5ccfbb1f7eb3072a9bb6e87c5e98b9/tests/Network/MultiplexTest.cpp#L143-L227
this segfaults when pushing a value and removing a protocol at the same time.. I wasn't expecting to need a mutex on updating parameters
is this a bug that I should submit an issue for or should I try another approach first?
I wasn't expecting to need a mutex on updating parameters
so, what is already mutex-protected is set_value / push_value
this can be called from any thread
hmm but this assumes that the structure of the device is indeed not modified in the meantime
alright pack it up folks, we migratin' to rust :p
I think it'd be useful to think how it would be done there. problem is that the lifetime of the protocol has to be preserved long enough ; when things occurs across threads I assume that Arc has to be used there. But in libossia at the beginning we also used std::shared_ptr to keep the parameter objects alive
but this was way too slow in large patches (5K+ parameters) thus moving back to non-shared ownership and the condition of "the structure does not change during execution"
and, haven't profiled it really
looks like i used reader writer locks and messages.. again, i haven't used this in anything "production" so I'm not sure if it would hold up.. https://github.com/x37v/oscquery-rs
regarding the issue I think that what we could do is, in stop_expose_to / expose_to, to push the object to be deleted in the async queue
and change push_value so that instead of accessing the device directly, it pushes an async event on the queue too, in order to serialize things
but that's quite a performance hit for the "usual" use case where the tree is created at the beginning and does not change afterwards
is provide another implementation of the parameter class
could you make an issue (unless there's already one, I don't remember) ? I have some time to spend on libossia these days so I'll try to come up with something to test
or maybe we could add a push_async instead... there's likely multiple possible designs
cool thanks ! i'll try to flesh out something on the issue and we can see if that solve your issue, and if you want to do it it would be great ! I think it's mostly about making sure that the parameters get an io_context in which they can push events
great!
@jcelerier here's the test and a mutex wrapped multiplex protocol that resolves the problem: ossia/libossia#795
i made it a Draft just cuz I thought you might have some other ideas as it is a lot different than what we talked about above..
i made it a Draft just cuz I thought you might have some other ideas as it is a lot different than what we talked about above..
I'm trying to build libossia for raspi.. I've done it a number of times in the past but now i'm running into an assembler error:
/home/pi/local/src/libossia/src/ossia/network/oscquery/oscquery_server.hpp:50:8: warning: by ‘virtual bool ossia::oscquery::oscquery_server_protocol::push(const ossia::net::parameter_base&, const ossia::value&)’ [-Woverloaded-virtual]
bool push(const net::parameter_base&, const ossia::value& v) override;
^~~~
{standard input}: Assembler messages:
{standard input}:605: Error: selected processor does not support `yield' in ARM modeI'm doing websearches to try to resolve it (maybe some cmake flags I can augment) but figured I'd check in to see if someone here has a quick solution
7 replies
@x37v while looking for solutions, I found this interesting thing re. thread safety: https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
2 replies
the good thing is that the code can be annotated incrementally