0000825: Add support for system signals to luxconsole

(0002394)
dougal2 (administrator)
2010-09-14 04:15

bump ;)

(0002405)
Grandmaster_B (reporter)
2010-10-02 16:17

In the forum some said the render servers/nodes are stopped when the master GUI is closed but unfortunately that does not seem to happen here (all on Win7). The only way to stop a node from rendering a scene seem to be using a remote desktop, which of course is tedious... even more when using multiple nodes.

(0002455)
Lord Crc (administrator)
2010-10-25 15:26

I've managed to implement a very basic system using boost::interprocess::message_queue. This won't work with slaves as the render server core needs to be rewritten to be async, but it allows you to control any local luxconsole processes. Once the server core is rewritten it'll be easy to extend it to slaves as well.

Example syntax:
luxconsole --ctrl pause
luxconsole --ctrl threads=4

Valid commands are "pause", "resume", "stop", "threads". I'd like to implement a "kill" but I haven't found a crossplatform solution yet.

(0002456)
Lord Crc (administrator)
2010-10-25 15:27

Actually, when running as a slave only stopping will be an issue IIRC. I'll check it out.

(0002962)
Lord Crc (administrator)
2011-04-22 06:38

I'm a bit confused at the moment jeanphi. You did not seem very eager about this addition, however you've targeted it for 0.8.

(0003026)
jeanphi (administrator)
2011-05-13 07:01

Quitting gracefully when asked to would indeed be nice and shouldn't be that difficult to implement in a cross platform way with boost.
Other features, I think should be postponed.

Issue History
Date Modified	Username	Field	Change
2010-08-14 10:11	SATtva	New Issue
2010-09-13 11:14	dougal2	Relationship added	has duplicate 0000861
2010-09-14 04:15	dougal2	Note Added: 0002394
2010-10-02 16:17	Grandmaster_B	Note Added: 0002405
2010-10-25 15:26	Lord Crc	Note Added: 0002455
2010-10-25 15:26	Lord Crc	Assigned To	=> Lord Crc
2010-10-25 15:26	Lord Crc	Status	new => confirmed
2010-10-25 15:27	Lord Crc	Note Added: 0002456
2010-10-25 16:42	Lord Crc	Relationship added	related to 0000875
2010-11-02 00:50	jeanphi	Target Version	=> 0.8RC1
2011-02-13 00:38	jeanphi	Target Version	0.8RC1 => 0.8RC2
2011-03-19 05:59	jeanphi	Target Version	0.8RC2 => 0.8RC3
2011-04-17 11:11	jeanphi	Target Version	0.8RC3 => 0.8
2011-04-22 06:38	Lord Crc	Note Added: 0002962
2011-05-13 07:01	jeanphi	Note Added: 0003026
2011-06-06 08:21	jeanphi	Target Version	0.8 => 1.0
2012-08-21 06:39	jeanphi	Target Version	1.0 => 1.1
2012-08-21 10:16	jeanphi	Target Version	1.1 =>

Notes
(0002394) dougal2 (administrator) 2010-09-14 04:15	bump ;)

(0002405) Grandmaster_B (reporter) 2010-10-02 16:17	In the forum some said the render servers/nodes are stopped when the master GUI is closed but unfortunately that does not seem to happen here (all on Win7). The only way to stop a node from rendering a scene seem to be using a remote desktop, which of course is tedious... even more when using multiple nodes.

(0002455) Lord Crc (administrator) 2010-10-25 15:26	I've managed to implement a very basic system using boost::interprocess::message_queue. This won't work with slaves as the render server core needs to be rewritten to be async, but it allows you to control any local luxconsole processes. Once the server core is rewritten it'll be easy to extend it to slaves as well. Example syntax: luxconsole --ctrl pause luxconsole --ctrl threads=4 Valid commands are "pause", "resume", "stop", "threads". I'd like to implement a "kill" but I haven't found a crossplatform solution yet.

(0002456) Lord Crc (administrator) 2010-10-25 15:27	Actually, when running as a slave only stopping will be an issue IIRC. I'll check it out.

(0002962) Lord Crc (administrator) 2011-04-22 06:38	I'm a bit confused at the moment jeanphi. You did not seem very eager about this addition, however you've targeted it for 0.8.

(0003026) jeanphi (administrator) 2011-05-13 07:01	Quitting gracefully when asked to would indeed be nice and shouldn't be that difficult to implement in a cross platform way with boost. Other features, I think should be postponed.