-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make sure the transformer publisher is starte in regular scripts. #5
Conversation
As usual i'm open for better solutions. |
To me, this says: we should all use bundles. Once and for all. This forest of "if we have a bundle" or "if we don't" is beyond annoying. |
Seriously? |
Misread the diff ... the functionality does make sense ... sorry for the noise. The implementation, on the other hand ... See my comments. |
Orocos::Process.run(options) do | ||
@broadcaster = Orocos.name_service.get(name) | ||
yield | ||
end | ||
else | ||
start_time = Time.new | ||
Thread.new do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a dangling, never-ending thread. Horrible.
e2acd43
to
ab1b3b6
Compare
I updated the PR, but there is still a problem left, the process which was launced by Orocos.run (the transformer) did not get stopped automatically. If i run a script and ctrl+c the transformer is still running. Even if i call stop_broadcaster the broadcaster (task) get stopped but the process is still alive. |
If you want to stop things automatically, use the block version. That's the whole point of having a block construct used that way in Ruby: that whatever-cleanup-is-required is done. Orocos.run when called without a block returns the set of processes that have been started. Pass them to Orocos.guard the same way than Orocos.run-with-a-block does (see https://github.com/rock-core/tools-orocosrb/blob/master/lib/orocos/process.rb#L829), or check Orocos.guard if you really really want to do it manually. |
Do i need a thread in this case? |
Let's walk one step back The only way you can guarantee cleanup is by having a form
which is essentially what Orocos.run with block / Orocos.guard do. Why isn't that good enough for you ? |
ab1b3b6
to
c559872
Compare
updated, hope this is what you have expected. You first mentioned that i should use Orocos.run without a block. So i don't need a thread anymore. Then you suggested Orocos.guard for which i need a thread. This is what confuses me. |
We had a few times that the transformer does not work correctly when bundles are not used. The problem was that the broadcaster did not get started. This PR automatically starts the broadcaster if this was not done before.
Why do you NEED a block-less version ? |
(and, you know how much I like threads, no ?) |
OK. This is getting too far. You want automated "under the scene" start/stop of the transformer broadcaster ? Use Bundles.run. You want to start the broadcaster manually and get automated stop ? Use the block form of start_broadcaster. Otherwise, you have to do your own cleanup. |
And all of these are process objects. They are asynchronous. You can kill them by, you know, looking into the Process API and finding out that kill is what Orocos.run and Orocos.guard do ! |
I only want to recover behaviour how it is documented. And still dont know what your solution would be. And yes i still will keepborocos.run support for the Transformers.... |
That is probably the root of the misunderstanding, then. What "documented behaviour" are you referring to ? |
Ok so let's restart hereMy thougts on this PR
regarding Orocos.run <-> Bundles.run:This is a larger discussion, it's not a orocos.rb thing in the end, it's the way how far plugins should use automate things. We have two ways:
I don't care so much when plugin do "magic" the scope is really limited to the plugin itself, thats why i would say it's not nice but okay here. It we would have a ruby-based deployer this would make it easier and not require such threads. summaryWhen you @doudou still want to go for 1. i would like to ask other dev's on the ML for a base-decision if you are fine with that. It's more a design principle at this point. If we go for 1) i don't reject and i will rework this PR and the DOC. But i would prefer 2. |
I would go with 1) in order to have a clear (in the sense of understandable for users) startup of the transformer in orocos scripts. |
Then i have no idea howto start the broadcaster nicely (without having a large overhead like the functions i propose) but i'm open for solutions... |
What I am again wondering is why the current API bad for you
|
Wrong button .. sorry |
Don't know this before... On 21.10.2015 12:05, Sylvain Joyeux wrote:
Dipl.-Inf. Matthias Goldhoorn Universität Bremen Zentrale: +49 421 178 45-6611 Besuchsadresse der Nebengeschäftstelle: Tel.: +49 421 178 45-4193 Weitere Informationen: http://www.informatik.uni-bremen.de/robotik |
I created a Issue on the doc (for now) and close this |
We had a few times that the transformer does not work correctly when
bundles are not used. The problem was that the broadcaster did not
get started. This PR automatically starts the broadcaster if this
was not done before.