When I speak about 'threads' in Ragel it is at a conceptual level. It is not the same as an operating system thread. In ragel, a thread's only state is the current state variable, which indicating that the state machine runtime is attempting to match a defined pattern. There can be many such patterns that is is attempting to match. This precludes storage of any kind of thread identifier at runtime that is associated with the current state. Instead, it would have to be handled at compile-time, through action rewriting. This is far beyond the scope of the current implementation. Instead the solution is to achieve the same thing by hand, as I previously described.
> (1) requires more boilerplate Yes. Such is life. A previously proposed macro system for ragel would relieve this somewhat, but so does relaxing a little bit and moving on to more concrete problems ;) > (2) is less efficient No, would be more efficient. > (3) doesn't work in a sub-machine, since it requires fcall/fgoto No, does not require fcall/fgoto. _______________________________________________ ragel-users mailing list [email protected] http://www.complang.org/mailman/listinfo/ragel-users
