Re: Steps to get multiple interpreters per process...
From:
Chris Ross <chris@...>
Date:
2002-06-25 08:16:01 UTC
List:
ruby-core #191
On Tue, 25 Jun 2002 02:50:45 Sean Chittenden wrote: : > |Can someone chart out what would need to happen to get multiple : > |ruby interpreters per process that way myself and others can do the : > |leg work? -sc : > : > We have to list all global variables and pack everything into a : > interpreter struct (like Perl guys did once). YACC parser still : > uses globals, but it must be another story. The YACC parser can be made re-entrant by using Bison and the directive %pure_parser. It is also possible to pass a pointer to the yyparse() call by doing: #define YYPARSE_PARAM parm Where you then can access the data passed to yyparse() with the name parm in the rules of the grammar. My main issue is lex, it is completely un-thread safe and is therefore damn near impossible to use to allow for concurrent compilation. One of these days I am going to rework these tools to remove global variables and states to make them threadsafe. The only part of ferite I can't get completely concurrent is the compilation - I have to do higher level locking. : Makes sense. What I don't fully understand (I've been staring at this : screen for too long and am about to go for a run, so bare with me) is: : : *) Once the globals are contained in a struct, where will they live? : In a global list that gets locked every time a new interpreter : instance gets added to the process? You would either have to: 1) Pass the structure a round the program such that it is accessable, both php and ferite do it this way [not sure about others as I have not looked in a while]. 2) Thread specific data - the global data has a key, whenever you want the global data you get the pointer to by calling a method. The bad thing here is the obvious speed hit. Go and see "man pthread_key_create" for the concept. Either way is a nasty conversion [I had to do (1) in ferite]. (1) is a much better long term goal. : *) How will functions that need to make use of this structure identify : which stuct in the list is theirs to play with? If you just pass the 'context' to each function and onwards [at first it feels very odd] you actually remove any headaches, they are all just accessed like local variables. : As an after thought, once the globals are all contained, someone with : Win32 knowledge could easily implement a win32 fork call that uses : CreateProcess() and then pass only the data structure to the new : process. I'm going off of what I've skimmed from the PostgreSQL guys, : but that'd put another nail in the cygwin coffin. What you are talking about there [I believe] is (2) with regard to thread specific data. Regards, Chris -- +------------------------------------------------------------------+ | Chris Ross | chris@darkrock.co.uk | ctr@ferite.org | | | http://www.darkrock.co.uk | http://www.ferite.org | +------------------------------------------------------------------+ "Life is an onion and one peels away its layers crying."