Instead it seems I've wasted everyone's time by posting code which is too incomplete. I didn't want to bog down my example with too many details. I think some of your questions about my code could be answered by adding a more complete example. How would I do this without #wait? Lock#acquire is pretty much exactly the behavior I want, so I don't see the conflict. Instead, it's similar to calling lock.acquire(), with the object that you're calling it on acting as a lock.Įven if I passed in services from the GUI thread, I would still need to pause them at times. It does NOT suspend the task or executor that you call it on. I'll study this a bit.Īgain, wait() does not do what you think it does. Looks like I pass the former a Task whereas I pass the latter a Runnable.
From the cursory peek just now I see that it is syntactically similar to ScheduledThreadPoolExecutor. Thanks Stephan, I will look into ScheduledExecutorService. You don't need to cancel it if you run it only once. Just call ScheduledExecutorService.schedule() with a custom Runnable (NOT TimerTask) and let it run to its end. The root of the problem is that you're mixing TimerTask with ScheduledExecutorService.
A class which extends Task isn't running concurrently until I call Task#call, so there's no risk of the constructor not finishing before other operations begin (as far as I know). I suppose I can start the thread from the GUI itself, where the Task is created, but why not put it in the constructor. In your updated could you are literally calling Thread.start(). In your previous code it was done indirectly. Why not just make them as needed and throw them away? I'm thinking it probably has something to do with what the java docs say about Interface ExecutorService, "An Executor that provides methods to manage termination and methods that can produce a Future for tracking progress of one or more asynchronous tasks." I suppose of the services are all necessarily the same between objects from the GUI, I can keep them synchronized more easily?Īgain, for emphasis, NEVER trigger threads from constructors. I'm not clear why a service is any different from any other object. This applies to all services that your classes depend on, not just executors. Pass executors into your FilePrinter through the constructor. It must run at a fixed delay.ĭon't let your services create their own executor services. That code does not strictly need to run asynchronously. Stephan van Hulst wrote:Before I can give you a good example, you need to explain carefully to me why the code inside the TimerTask needs to run asynchronously with respect to the code inside the Call() method, seeing as that code is already running asynchronously with respect to the front-end. Has anyone else encountered this type of compatibility issue? Any suggestions or tips would be very much appreciated. The behavior is the same when I run this shell script in terminal (script replies with "Bad CPU type in executable").
As I mentioned, the application doesn't even launch. Second, I wonder if there is a meaningful way to change the script "installbuilder.sh" so this thing will run.
I don't know if this will work with any Frankenstein compatibility layer out there. If this is intended for 32-bit intel-based Macs only, perhaps I'm SOL since MacOS ditched 32 bit support. From my very limited knowledge of software engineering (I really only know java and some python), I keep thinking back to how the installer might be handling CPU architecture.įirst, I'll note something I forgot to mention in my first post.
0 kommentar(er)
