<ysionneau>
sb0_: fyi, I tested my ping_controllers branch with a ddb containing a wrong controller path, it just spawns the process, which fails, and it retries (as if the process really existed but died)
<ysionneau>
so it does not get stuck
travis-ci has joined #m-labs
<travis-ci>
m-labs/artiq#293 (master - 8a33d8c : Sebastien Bourdeauducq): The build has errored.
antgreen has quit [Remote host closed the connection]
<sb0_>
ysionneau, does this test appropriately that monitoring returncode will indicate process termination if the executable doesn't exist and the process never started?
<sb0_>
or do you not get a process object at all in that case?
<ysionneau>
let me redo the test, but IIRC it returned a process object, and return code was set
<ysionneau>
ah no
<ysionneau>
process is NnNone
<ysionneau>
None*
<ysionneau>
it goes through the FileNotFoundError
<ysionneau>
but, that's good, isn't it?
<sb0_>
it's definitely good to understand what your code is doing, yes
<ysionneau>
sure =)
<sb0_>
ysionneau, was the AsyncioClient.__getattr__ method broken?
<sb0_>
oh, the return values were not passed correctly, is that it?
bentley` has joined #m-labs
<ysionneau>
it's just that the do_rpc coroutine was not yielded from
<sb0_>
yes. and the effect of that was the RPC return values weren't passed on, wasn't it?
key2 has quit [Ping timeout: 246 seconds]
<ysionneau>
yes
<sb0_>
ok. can you commit that fix and the asyncio_process_wait_timeout rewrite directly to m-labs/artiq?
<ysionneau>
ok sure
<sb0_>
and I guess that closes #56.
<ysionneau>
yes
<ysionneau>
let's do that
<sb0_>
I would move the ping task to Controller and have one task per controller
<sb0_>
this way the ping rate doesn't depend on how many other controllers there are and how fast they respond
<ysionneau>
ah yes
<sb0_>
and I guess it's a good idea to have the ping rate and timeout configurable, maybe on a per-controller basis in the ddb
<sb0_>
hmm, the ping could be: create RPC client, connect, ping, disconnect, destroy RPC client
<sb0_>
that would be much simpler than trying to keep a connection active in the background
<sb0_>
and less bug-prone
<sb0_>
when ping fails, you can simply notify the local launcher task to restart the controller
<sb0_>
or even integrate the ping into the launcher.
<sb0_>
yield from process.wait() with a timeout equal to the ping period
<sb0_>
and test if you returned because of timeout (then ping) or process termination (then current mechanism)
<GitHub42>
[artiq] fallen pushed 1 new commit to master: http://git.io/vqENi
<GitHub42>
artiq/master 2d343dd Yann Sionneau: pc_rpc: AsyncioClient __do_rpc coroutine was never yielded from
<GitHub70>
[artiq] fallen pushed 1 new commit to master: http://git.io/vqExR
<GitHub70>
artiq/master 0109821 Yann Sionneau: tools: change asyncio_process_wait_timeout to handle cases where process.stdout is None. close #56
<ysionneau>
sb0_: ack for those changes for the ping controller branch
<sb0_>
meh, is there really no way to load windows dll in linux?
<sb0_>
something like libffi that would use wine...
<sb0_>
blerg
<felix_>
ardour can load windows vst plugins (which are dlls) with some wine inbetween iirc
<felix_>
so it is possible, but ugly and had some stability problems when i tried that maybe 6 years ago
<sb0_>
seems you can build something that can access both win32 and linux APIs using winegcc