From mboxrd@z Thu Jan 1 00:00:00 1970 From: elfring@users.sourceforge.net (SF Markus Elfring) Date: Tue, 25 Aug 2015 08:42:54 +0200 Subject: [Cocci] release: 1.0.2: Software evolution around parallelisation support In-Reply-To: References: <55DA0DFD.8090005@users.sourceforge.net> Message-ID: <55DC0E6E.10405@users.sourceforge.net> To: cocci@systeme.lip6.fr List-Id: cocci@systeme.lip6.fr >> Does the parallelisation support need any more fine-tuning? >> * How often is task preparation required before further data processing >> can be performed in parallel? >> >> * Which programming interfaces do you prefer for the storage >> of collected data in the fork-join work flow? > > No idea what either of these questions mean, but the whole point is that > there is no join. This view needs an adjustment. A fork-join work flow is implemented by the Coccinelle software for its main programs with the help of the application programming interface "parmap", isn't it? https://rdicosmo.github.io/parmap/ The manual contains the following information for this approach. * Preparation for spawning subprocesses: "This option furthermore creates a temporary directory in the directory from which spatch is executed that has the name of the semantic patch (without its extension) and that contains stdout and stderr files generated by the various processes." * Actions for joining: "When the semantic patch completes, the contents of these files are printed to standard output and standard error, respectively, and the directory is removed." I propose to reactivate the support for the SmPL rules "initialize" and "finalize" for all uses cases without unwanted software limitations. I imagine that such rules can still be evaluated and executed at the appropriate data processing phases after a bit more software development even if the multi-programming technique is reused. Regards, Markus