As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am looking for a Threading framework to use in my Delphi application.
Currently I am evaluating ‘OmniThreadLibrary’ - so far it looks good and does everything I need.
Is there any other ‘Threading framework’ for Delphi ?
(I am using D2006 & D2009)
As per Vegar Suggestion
Based on my few hours of evaluating OmniThreadLibrary
Here are some of the things I like about it
1) It is simple to use
2) It hides most of the details about multi threading
3) With a few lines of code you can set up multiple threads
4) It is easy to do inter process messages
5) It is still been actively developed
Not a framework as such, but there's AsyncCalls. Its scope is different from OmniThreadLibrary, but it supports older versions of Delphi as well.
Internet Direct (Indy) contains IdThread and thread safe data types in IdThreadSafe.pas:
* TIdThreadSafeInteger
* TIdThreadSafeBoolean
* TIdThreadSafeString
* TIdThreadSafeStringList
... and some more
The Jedi Code Library (JCL) also includes synchronization classes and functions (around ten classes)
I have been developing my own extensive threading framework, which is also integrated with a similarly architected communications framework, over the last 10 years. At this stage it can be used with Delphi 2005-2007, but will soon be available for Delphi 2009-2010. This application development framework can be used to build massively distributed systems as it is designed to enable any threads to run in any process and uses a simple thread-communications protocol that is the same whether the threads are in the same process, or in different processes on different machines.
As an additional feature I have this framework now running in C#/Visual Studio so a distributed system built using this framework can have a mix of Win32 and .NET applications, all using the same design methodology. The framework can be downloaded from http://www.adug.org.au/downloads/CSIFramework.html
The libraries that are used by my framework are not as extensive as it must have appeared from the site (I have just reworded that page, but it may take a day or so to be updated). Furthermore, all required files (apart from the database abstraction layer) are included with the framework, so no third-party libraries need to be installed to use the framework.
Beyond Delphi, the libraries used are:
Indy (included with Delphi, although I use the latest pre-unicode version)
JEDI JCL
Turbopower Abbrevia
an XML tidy library (optional)
a database abstraction library (optional)
I have modified some peripheral Delphi units 1) to fix a memory leak in the open XML implementation in Delphi 2006 (subsequently fixed in later Delphi versions), 2) to integrate the service application with my logging framework, and 3) to integrate the stand-alone SOAP server with Indy 10 (not Indy 9 as included with Delphi 2006).
In reality, my framework is much, much more than just a threading framework, although the threading framework is part of it. The threading framework is built by implementing all threads as threaded queues. The "messages" passed between the threaded queues are actually data packaged in a generic typed object, which allows me to pass absolutely any data structured in any way between threads. I can pass messages between threads either asynchronously, by adding a message, or synchronously, by adding a message and receiving a message in response. The threads themselves subscribe to other threads to receive messages, so there is no coupling between the threads at design time.
This framework has been extended to include communications servers and clients, and the main GUI thread, to have exactly the same messaging interface as the threaded queues, so sending a message to a remote process, or passing it onto the GUI, uses the same syntax as that used between threads. The framework has been designed in a way that there is no requirement to know anything at all about multi-threaded development to build a distributed system deployed across multiple processes and multiple threads.
There is a lot more to the framework than this and I have put in more than 2 years worth of effort to develop this over the last 10 years. It has been successfully deployed in a multi-tier alarm monitoring system (utilising over 20 different classes of thread across three applications), and I am currently building a distributed system in Visual Studio 2008 using this framework.
In short, if all you want is a simple threading framework, then this is probably overkill. However, if you want to develop a complex multi-threaded system which might span multiple applications then the learning curve may be worth it.
PS Another few points:
Thread startup and shutdown is all handled by the framework (no need to write any code to do this)
The threads that comprise the application (number and configuration) are all defined in an an XML configuration file, not in the code itself (no need to write any code to include them in the application)
If you use the database abstraction component then multi-threaded database access is automatically available (no extra code required)
I am currently working on adding thread pooling, which will allow any threaded queue to have a specified number of instantiated threads (again, no need to write any code to do this)
There is a simple developer's guide that you can download from the web page which is also included in the framework download that gives an overview of the framework from a developer's perspective
The framework itself is under very active development, and with the next release of Delphi I hope to have a version running on Win32 (under Delphi), a .NET version (C#/Visual Studio), and a Linux version (using the new Deplhi cross-platform compiler)
Related
I'm writing a Swift client to communicate with a server (written in C) on an embedded system. Its not iOS/OSX related as I'm using the recently released Ubuntu version.
Does Swift have any native support for concurrency? I'm aware that Apple discourages developers from using threads and encourages handing tasks over to dispatch queues via GCD. The issue is that GCD seems to be only on Darwin (and NSThread is a part of Cocoa).
For example, C++11 and Java have threads and concurrency as a part of their standard libraries. I understand that platform specific stuff like posix on unix could be used under some sort of C wrapper, but for me that really ruins the point of using Swift in the first place (clean, easy to understand code etc.).
2021 came and...
Starting with Swift 5.5, more options are available like async/await programming models and actors.
There is still no direct manipulation of threads, and this is (as of today) a design choice.
If you’ve written concurrent code before, you might be used to working with threads. The concurrency model in Swift is built on top of threads, but you don’t interact with them directly. An asynchronous function in Swift can give up the thread that it’s running on, which lets another asynchronous function run on that thread while the first function is blocked.
Original 2015 answer
Quoting from Swift's GitHub, there's a readme for "evolutions" :
Concurrency: Swift 3.0 relies entirely on platform concurrency primitives (libdispatch, Foundation, pthreads, etc.) for concurrency. Language support for concurrency is an often-requested and potentially high-value feature, but is too large to be in scope for Swift 3.0.
I guess this means no language-level "primitives" for threading are in the pipeline for the foreseeable future.
I dont want to compare apple with orange, this was already done, for example, in:
http://blog.shinetech.com/2011/06/10/nodejs-from-the-enterprise-java-perspective/
http://adamgent.com/post/10440924094/does-java-have-an-answer-to-node-js
Actually, I do not have a concurrency problem with JBoss AS 7, but if I had on, what should I do?
Should I:
SOLUTION I:
horizontal/vertical scale
use HTTPD in front of JBoss AS
use #Asynchrounous or Messaging Systems (such as AKKA) for ALL tasks
...
SOLUTION II:
use node.js (rhino.js)
Can anyone provide practical experiences where JBoss AS 7 failed to scale? I have never had such experiences for myself.
For example, imagine a web application with 10.000.000 concurrent request *on a single machine* (with a single jboss-as-instance or a single node.js-instance).
What would be the result?
Would node.js works normally while JBoss AS 7 crash?
In general, Java EE is primarily targetted at high-scale application and most of the design decisions comply to that, from persistence over session and cache replication to view layers.
While Node.js may be good for certain tasks, Java EE 6 is (IMO) good if you want to use it for whole stack.
There's more comming regarding scalability, like JSR-352. So Java EE is yet to improve.
Regarding your question - "while JBoss AS 7 crash" - it doesn't generally crash. Usually it's faulty or poorly written application what crashes. Node.js gives certain API. Java EE gives a multitude of APIs, which sometimes are misused or conceptually misunderstood, which results in problems like OutOfMemoryException. With a properly designed application, there should be no problem with horizontal scaling.
There are few proven examples of node.js supporting a large and popular application as of yet. Like any new technology of this type, it will get tested and if it scales will garner support. Nobody can truly answer your question from a technical standpoint.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I see a lot of potential of doing Node.JS-like development on the JVM, with its heavily optimized runtime.
At this moment in time, I see three projects that aim to bring a node.js-like style of development to the JVM:
Apache Deft
Webbit
Vert.x (formerly Node.x)
Should these projects team up?
What are their relative strengths and weaknesses?
Which project has the most momentum?
Disclosure - I'm the vert.x guy :)
Vert.x is a fully fledged platform for building polyglot, scalable, asynchronous web-enabled applications.
It is heavily inspired from node.js but goes further than node.js and provides a distributed event bus which reaches from the server right into client side JavaScript thus creating a super simple model for so-called "real-time' web applications. We also ship with a mailer and a mongodb persistor. There's a full tutorial here http://vertx.io/tutorials.html
But the probably the main thing that sets it apart from other async frameworks is it's polyglot nature. The same (or similar) API is available in Java, Ruby, JavaScript and Groovy (with Clojure, Python and Scala support to follow).
Vert.x really takes advantage of true multi-threading on the JVM to provide scalability and performance than node.js cannot touch.
If you don't want the whole platform. Vert.x can also be used as a library for providing HTTP, TCP, websockets, sockjs, eventbus, etc support in your Java or Groovy application.
For more info pls see the website http://vertx.io
Disclaimer: I'm the Webbit guy
There is definitely a lot of overlap between the 3 projects. When I built Webbit I was not aware of the other two - had I been, it may well not exist, or I may have spent my time contributing to the others.
I can talk a bit about Webbit...
It is not a multi-purpose evented IO framework. Or network protocol toolkit. Or filesystem abstraction. Webbit only does a small fraction of what the others do.
Webbit is also not a full-featured web-framework. Like Node.JS or the Servlet API, it provides the core building blocks for building higher level frameworks, but leaves this to external projects (like Webbit-EasyRemote or Webbit-REST).
What Webbit focuses on is being a simple, embeddable, non-blocking, HTTP and WebSocket server.
Because it takes the 'do one thing and do it well' approach, it has also been designed to be used in conjunction with other libraries. It allows external java.util.concurrent.Executors to be passed in and avoids singleton thread contexts, making it particularly well suited for integrating with Actor style concurrency libraries such as Jetlang and HeySync.
Vert.x and Deft bring complete frameworks for out-of-the-box Node style development. Webbit is just a small tool that can help HTTP/WebSocket enabled your application. There is a need for both of these and it really depends on your needs (and personal style) as to which is more appropriate.
Disclaimer: I'm an Apache Deft committer.
Apache Deft has more in common with tornado and twisted than to node.js, whereas vert.x is heavily influenced by node.js. Tim Fox from wmware is doing a great job with vert.x and the development speed is really impressive.
vert.x has a couple of examples available.
Some Apache Deft examples.
Apache Deft also has a bigger "demo application" that should give you an idea of how you could use the framework for other things than http.
AFAIK webbit is currently aiming to be a "WebSocket and HTTP server".
If they should team up? Absolutely :)
While multithreading is faster in some cases, sometimes we just want to spawn multiple worker processes to do work. This has the benefits of not crashing the main app if one of the worker crashes, and that the user doesn't need to worry a lot about inter-locking stuffs.
COM+'s Application Pooling seems like a good way to achieve this on Windows. The downside is that we need to write a COM+ wrapper for the worker process.
However, when I search for Application Pooling on Google, it seems like most of its usages are related to IIS. Don't other applications (such as scientific/graphics) find it useful to spawn multiple worker processes?
So there are several questions:
Why isn't COM+ more popular in areas other than IIS? If I write a non-IIS application and want to use process management on Windows, should I go with COM+ or are there better alternatives out there?
What would be the cross platform way to do it? Are there libraries out there that give me a "process pool" (worker processes will intelligently pick up work, can be managed, etc.)
I can't offer any answers to the COM aspect of your question, but it's worth noting there's another world (besides HPC MPI) where multi-processing (rather than the more common multi-threading approach) is apparently alive, well and thriving: Python.
Why ? Python's GIL ("global interpreter lock") cripples most attempts to multithread python code so badly that multiprocessing is the generally recommended approach to parallelising Python on SMP. The standard library includes process pools; there are various other options too.
Python certainly ought to satisfy any multi-platform requirement!
You might want to investigate how the apache web server manages process pools. From version 2.0 it runs natively on windows and one of the multi-processing models it supports are process pools. A part of apache is also APR (apache portable runtime), which handles platform-specific issues.
No one can answer why something is not popular because may be no body is looking for what you are looking for. After .NET came in picture, people shifted from COM to Managed Environment, before .NET, COM and ATL and relative other technologies were quite painful to implement and they would crash and were also quite difficult to debug.
That is the reason, managed environment came in existence.
However, .NET 4 onwards, parallel libraries give much more power to user for parallel programming and also you can spawn and control other proceeses.
For multiplatform, you can look for zvrba's answer.
Yes, other applications--especially science applications--find it useful to spawn multiple processes. Since few super-computers run Microsoft Windows, scientists generally avoid using anything that ties them to a Microsoft platform. Nothing related to COM will help scientists leverage their enormous existing code base written in Fortran.
People who choose to run IIS have generally already drunk the Microsoft Koolaid, so they have fewer inhibitions to tying themselves to Microsoft's proprietary platforms, which is why COM-specific terminology will get lots of hits related to IIS.
One of the open standards for doing what you want is the Message Passing Interface. Several implementations exist and some of them run on supercomputers using Fortran. Some of them run on cheaper computers using sexier languages.
See http://en.wikipedia.org/wiki/Message_Passing_Interface
There hasn't been a mob rushing through the doors of COM application pooling primarily because of two factors:
COM is a pain in the ass to deal with compared to just about anything else
Threading can be a headache, but it's a lot easier and more convenient to manage than inter-process communication
COM application pooling was essentially created for IIS. It has one very specific benefit over normal multithreading: the multiple processes are fully isolated from each other. This is important for data security and for app stability when dealing with third party plugins of questionable stability.
Scientific computing generally doesn't need strong data security isolation between operations, and I would venture to guess that scientific computing doesn't rely much on third party plugins of questionable stability. When doing big math operations, you're either using a sexy numerics library that had better be rock solid to be taken seriously, or you're using your own code, in which case crashes should be fixed and repeat offenders should be spanked.
Oh, and all crashes except stack overflow can be trapped and dealt with within a multithreaded app, especially if it's your own code.
In short, COM app pooling is overkill for just about anything other than IIS.
Google's webbrowser chrome is a multi-process architecture software. It is open source, so you can check out its code and see how to manage processes.
What is the difference between the next terms, it can help a lot in interviews and general understanding.
Framerwork
Library
IDE
API
Framework
Some predefined architecture that a developer has chosen and which dictates how the application will be written. It usually already includes many concepts which helps the developer to concentrate on the domain of the application instead of the plumbing. This plumbing is provided by the framework. For example the .NET framework provides out-of-the-box tools that would allow you to talk to web servers, without even knowing the internals of the TCP/IP protocol (actually it helps knowing the internals but you get the point).
Library
A reusable compiled unit that can be redistributed and reused across various projects. Well not necessary compiled in case of dynamic languages.
IDE
It's the development environment where you create the other three parts (usually text editor), it might also include compiler and the possibility to execute, debug and see the output of the program in order to speed up the development process.
API
Application Programming Interface. This could mean many things but usually it is a set of functions given to the disposition of the developer and which perform specific tasks and work only in a specific context.
IDE is a tool for fast, easy and flexible development
An API is provided for an existing software. Using these third party applications can interact with main/primary application.
A framework or library are typically same. They are a common set of functionality for other software to use.
Ref: wiki for Framework, API
Framework: a collection of libraries and programming practices to provide general functionality for a program, so that it doesn't have to be rewritten. Typically a framework for an application program will handle user display and input, among other things. The intent is usually to hide the more complex functionality of an application, and to encourage a certain style.
Library: A piece of software to provide certain functionality to other programs that call it. Typically designed to be reusable and modular, so that a library can be distributed and be useful without its source code.
Integrated Development Environment: A integrated set of tools to write programs and turn them into finished products, usually including at least an editor, compiler, linker, and debugger. IDEs sometimes provide support for frameworks.
Application Programming Interface: A set of function calls and sometimes variable accesses available to a program, typically being the public interface of one or more libraries.