Re: [Hecl-devel] Issue with synchronized eval
Brought to you by:
davidw
From: David W. <dav...@gm...> - 2008-01-22 09:53:05
|
> Back to eval: > Assume you implement a command in Java that waits for something and > wants to give other hecl code (async, event, timer) the chance to be > evaluated, take http.get as an example. A different thread is created at > Java level that needs to call interp.doonevent to give Hecl a chance to > proceed. This results in a situation with multiple threads accessing the > some interp, so synchronization is a serious issue we need to address. In that example, though, it's not the new thread that is calling doOneEvent, but the main thread that spawned the child thread. Maybe we should take that pattern and make a standard API for it? Thinking about it, how does it work: * Some command implemented in Java launches a thread. * If it needs to wait for the thread to finish (like in the case of http.get), then it's going to enter a loop checking to see if its thread is finished, and also calling doOneEvent. So far so good. I don't know if that sort of thing is terribly efficient/elegant, but it seems to work ok for the moment. What else might happen, and how do we handle it? * Some command launches a thread and just lets it go, returning immediately. Normal execution continues. The tricky thing might be if we want to do something - a callback, say - when the spawned thread finishes. > > Argh! What's incompatible with them? Would it be possible for > > j2mepolish to work on the already-processed files in the build.../pre > > directory? > They use a different preprocessor that does not understand float > constants like java.version=1.5 and interprets everything as a string. > Unfirtunately, the new antenna 2 preprocessor does not support the > option to eliminate processed preprocessing statements from the output:-( How frustrating:-( Let me see if I can contact the new Antenna maintainer to see if he has any ideas. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ |