[Glass] Problem with #fork and #performOnServer?

[Petr Fischer via Glass]

> Hi guys,
> 
> I am trying to accomplish something easy: I have a main gem that iterates
> some "reports" and exports each report into a PDF by calling a unix lib.
> This PDF export takes some seconds. So what I wanted to do is something
> like this pseudo code:
> 
> self reports do: [:aReport | [  System performOnServer: (self
> pdfExportStringFor: aReport)  ] fork ].
> 
> What I wanted to do with that is that each unix process for the PDF tool
> was executed on separate CPU cores than the GEM (my current GemStone
> license does allow all cores). However, I am not sure I am getting that
> behavior. It looks like I am still using 1 core and being sequential.
> 
> Finally, I couldn't even reproduce a single test case with that I had in
> mind:
> 
> 1 to: 6 do: [:index |
> [ System performOnServer: 'tar -zcvf test', index asString, '.tar.gz
> /home/quuve/GsDevKit_home/server/stones/xxx_333/extents' ] fork.
> ].
> 
> I would have expected those lines to burn my server and use 6 cpu cores at
> 100%. But no, nothing happens. What is funny is that if I call the very
> same line without the #fork I do get the 100% CPU process:

Just a note:
tar/gzip is not written with multicore support IMHO, so you always utilize single core only to 100%. But there is "parallel gzip" (pigz), which definitelly turns CPU cooler to speed.
Usage: tar --use-compress-program=pigz ...

Is performOnServer: really non blocking for whole image/gem (or the whole VM simply wait for command to complete)?

> 
> System performOnServer: 'tar -zcvf test', 1 asString, '.tar.gz
> /home/quuve/GsDevKit_home/server/stones/debrisDemo_333/extents'
> 
> So....is there something I am not seeing with #fork and #performOnServer: ?
> 
> Thanks a lot in advance,
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com

> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass