Am 25.07.2013 20:43, schrieb Massimo Manghi: > As Rivet developer and Rivet packager for Debian/Ubuntu I wouldn't give > up the chance of having it installed onto any strain of Unix using the > Tcl library provided by the OS, whether threaded or not. I even proposed > a workaround for Harald's problem based on Tcl threads that achieved > what asynchronous programming failed to achieve given the missing > notifier (Harald rejected the solution on the basis of other constraints) > > Needless to say, if TCT decided that Unix fork (with the fork1 > semantics) is fundamentally incompatible with Tcl and hence assume to > have complete freedom at creating ancillary threads that could be in any > state by the time a fork is called we would take it into account.
Dear Massimo, I find it not so helpful so close to the aim to go back. I am still convinced that the achieved solution is good. We have no threads but the notifier thread and anybody who loads other threaded extensions in the init interpreter must be warned. For me, the init interpreter feature of Rivet is an expert feature. To save this feature, we gave up basic features like "fileevents". And saying - if you want to use fileevents (or packages how use it like tclws for rivet, http core package etc), use an interpreter in a sub-thread - sorry, we have to keep it easy, this is not a solution at all, if we make rivet complicated we have lost... I can understand that it is hard as a maintainer to support any configuration. But at least we have to try and get things better in future and this is what is achieved here. We have to keep the big aim in view, sorry... The tcl core list is IMHO hard to handle. You must do enough noise to get answers, be quick and responsive, but take care that it goes the way you like. You always have warning posts from the gatekeeper people Donal and Joe but this is their work and they do well. Don't get desperated due to that. But writing "we don't really want it" is the end of the solution, I fear. So what do I want in Rivet (in this order): 1) a full working standard tcl interpreter to use the whole tcl infra structure. 2) easy to install, use a standard installed tcl as far as possible. 3) expert features like threading and init interpreter In consequence, wheter we get this patch in (solving 1 and 2) or we make 3 optional Enjoy your holidays, I will be there next week, Sorry, Harald --------------------------------------------------------------------- To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
