On 06/12/2018 04:11 AM, Brice Hamon wrote:
Hi guys, I spent some time today trying to figure out why the share lib works fine under the tclsh but not within rivet. I haven't found the pattern yet. But so far: - If I have a vwait forever in the RivetChildInit script, my lib loads fine and all the threads are spinning nicely and my TCL callbacks are called.
I think Harald had the best understanding of the whole matter. This problem bit hard with him, didn't it Harald?
- But if I have a vwait forever in the RivetChildInit script, rivet is stuck and does not serve any incoming http requests.
I guess a 'not' is missing in this sentence
I tried to create a slave interpreter in the load, which passed it along the library ..._init C hookup function but this did not help. So this is not an easy one. Thank you Brice.
Not exactly a workaround, but rather an alternative solution worth exploring are Tcl threads. I never had a real need of using Tcl threads with Rivet scripts but I once made a test (I published this test in a message to this list) and they worked out. The test was simply a script that created a pool of threads doing something trivial and then the main thread joined with them listing the "order of arrival" of the threads in the pool. Do you think it can fix into your design? Another possibility, when everything fails and you need very fine control over the interaction with C/C++ code, could be.....writing a new specialized bridge. Yes, I know the downsides have to be careful considered, it's the most expensive solution in terms of development but you would have a total control over your threads communication -- Massimo Firma il tuo 5 x mille all’Università di Parma e aiuta così i nostri studenti che vogliono realizzare un’esperienza di studio all’estero – Indica 00308780345 nella tua denuncia dei redditi. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
