Jump to content

Search the Community

Showing results for tags 'webworker'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


There are no results to display.


  • Welcome to Smart Mobile Studio
    • News and Information
    • Pre-Sales Questions
    • Smart In the Media
    • Smart Contests
    • Meta
  • Smart Mobile Studio Discussion
    • General
    • IDE
    • RTL
    • Code
    • Client Server
    • Platform
    • Graphics
    • Deployment
    • Suggestion box
  • Smart Mobile Studio support
    • Support
    • Bug report
  • General Discussion
    • Pascal
    • Delphi
    • Javascript
    • HTML/HTML5
    • CSS
  • Resources
    • Website
    • Download Smart Mobile Studio

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL



Company name


Found 3 results

  1. WebWorkers and Flow Based Programming It has been a while since I got as excited as I was when I read J.Morrison's book "Flow-Based Programming: A New Approach to Application Development - 2nd edition". This post is not meant to give an overview of FBP, but if someone is interested, the first edition of his book is available online for free. FBP utilises independantly running processes which are wired together in an assembly line type of arrangement. The main advantages are that each process runs on demand rather than on availability, components can easily be re-wired to implement changes in requirements and there are possibilities for extensive component re-use. I was in the process of porting this framework to Smart, when I realised that javascript and concurrently running processes is not an easy match. Basically all js code in the browser executes in the same thread, and time-slicing mechanisms like setTimeout (used in the framework I was porting) doesn't enable real concurrent processing. However there are 2 exceptions to escape the single-threadedness : IFrames and webworkers. Both implement runtimes separate from the main thread and have their own heap, stack and message handling mechanism. The similarities between the FBP and shared webworker specs are (more than) striking, so this post is about having a go at implementing FBP using webworkers. Technically - processes (fbp) can be implemented through shared webworkers - connections between processes (fbp) can be implemented using channels (webworker to webworker, buffered) - ports (fbp) can be implemented using ports (webworker) - reading/writing of information packets's (fbp) can be implemented using messaging (webworker) - information packet handling (fbp) can be implemented using the transferable interface (webworker) The demo chosen is a variation of the 'Galaxy Clock' project in the featured-demo's section. The variation being that the 'single motor' driving the 3 hands of the clock (hr, min, sec) is replaced by 3 separate 'motors', each driving one of the hands and each one operating in its own thread. The architecture of this demo : a scheduler webworker receives the current local time when a button is clicked in the main program. It transfers the time-elements to each of the other web-workers through the channels created. These other webworkers in their turn update the main project at appropriate intervals. The result of this rather peculiar architecture. The hr/min/sec displays are purposely not synchronised and are all running at 10x normal clock-speed.
  2. Seems the RO interface need an update following changes in RTL files organization. To be able to execute run a TWebWorkerThread, I had to remove SmartCL.System and W3System units from RemObjectsSDK.pas Unknown "window" error. But now calling RO services still fail with this message: Uncaught ReferenceError: RemObjects is not defined
  3. lynkfs

    Multi threading

    Multi-threading The below approach works. My question though is, is there a simpler solution to the story-line below or is this it ? Computationally intensive tasks can be processed separately from the single thread main js-loop using webworkers. In this case I want to separate an existing processor-intensive procedure (TForm1.TrainNetwork) into its own thread. postMessage is the mechanism which can cross process-space divides and is how the main program and webworkers communicate. This is somewhat different from the CustomEvent mechanism described by Jon in this article. I found out that postMessage by the way works equally well in the same browser-tab, without using webworkers at all. To illustrate : the following statement TrainNetwork(<parameter>); could be replaced by posting a message and adding a listener : window.postMessage(['TrainNetwork','<parameter>'],'*'); window.addEventListener('message',procedure(evt:variant) begin case evt.data[0] of 'TrainNetwork': begin TrainNetwork(evt.data[1]); end; end; end, false); which works, but doesn't make much sense of course. It replaces a simple function call with sending a message, listening to it and then making the function call after all. However this is the pattern used with webworkers. For using webworkers, replace 'window' with 'worker' in the code above (and forget about the second '*' parameter in the postMessage call). There is a demo in the Featured Demos section on how to initialise and use webworkers. Which shorthands to var worker : variant := new JObject; asm @worker = new Worker('worker.js'); end; where 'worker.js' contains the logic of the worker. The simplest of workers just echoes incoming requests : onmessage = function(e) { console.log('Message received from main script'); console.log('Posting message back to main script'); postMessage(e.data); } although the following addListener construct, which produces the same results, is perceived to be better : self.addEventListener('message', function(e) { self.postMessage(e.data); }, false); Next step is to actually let the worker execute the TrainNetwork procedure. Since worker.js is javascript, it needs javascript. What worked for me is to use the command line compiler to compile TrainNetwork into TrainNetwork.js and include this file in the worker : self.addEventListener('message', function(e) { importScripts('TrainNetwork.js'); console.log('TrainNetwork executed'); self.postMessage(e.data); }, false); The limit to this approach is that workers cannot access the Dom at all, which means that TrainNetwork cannot have any visual contents. If for instance the results of the TrainNetwork procedure need to be displayed, then the solution will be to either - leave that to the main program - let the worker construct a set of visual objects with no reference to the dom, serialise them and insert them in the main program - let the worker construct a compound html string and insert this into the innerHtml property of some element in main
  • Create New...