Common Lisp implementation with CFFI and thread support on Mac, Windows, and Linux?
The last command is supposed to start Hunchentoot, then return to the interpreter for further Common Lisp forms.
For CLISP, SBCL, ABCL, ECL, and CCL, I get one of two results:
- Hunchentoot’s dependency Bordeaux Threads fails to install.
- hunchentoot:start hangs. The web page never loads, and never 404s.
4 Answers 4
AFAIK the win32 implementations of CLISP and SBCL don’t support multiple threads whereas Hunchentoot depends on this feature (dependency to Bordeaux Threads). Hunchentoot works well with Clozure Common Lisp.
LispWorks is the platform on which Hunchentoot was designed, and is available on all three operating systems.
Lispbox offers a working copy of CCL, CFFI, threads, Emacs, and SLIME. Quicklisp and Hunchentoot work well. There isn’t an installer yet, but the darn thing works 🙂
Regardless of OS, if this returns nil in SBCL, you’ll need to enable threads:
Enable threads: Using the pre-compiled SBCL, compile latest version from source, but note the INSTALL instructions on enabling threads. You’ll create a file called «customize-target-features.lisp» to contain the lambda expression given in the instructions. (Tip: compile from within ‘screen’ detached, redirect to log file or similar since a Terminal window may become i/o bound and actually slow-down the compile.)
SBCL pre-compiled for Linux has threads enabled, but pre-compiled for MacOSX, FreeBSD and Windows are without threads enabled. This may change with future releases.
Qt Threading code different behavior in MAC,Linux and Windows
I have written code for a server which accepts connections from different clients. Each client is serviced in different threads. Each thread accesses a database to get data and then updates this data to all the clients connected to server. 1) For the first time when UI asks data from server, it responds properly, but after that server does not read the socket i.e. Server’s readyread() doesn’t get invoked. Funnily enough, this works fine in mac and linux, this issue is seen only on windows 2) I was able to verify that when the DB module emits a signal which is caught by the threads, the hang occurs, Because everything worked fine when I removed the emit. Here, I am attaching all the needed .h and .cpp codes Defn.h
#ifndef DEFN_H #define DEFN_H struct PresetData< QString ID; QString name; QString value; QString source; >; #endif // DEFN_H #include #include "myserver.h" #include "mydb.h" int main(int argc, char *argv[])
#ifndef MYDB_H #define MYDB_H #include #include #include "Defn.h" class MyDB : public QObject < Q_OBJECT public: explicit MyDB(QObject *parent = 0); signals: void dataAvailable(QString ID, QString name, QString value, QString source); public slots: void onUpdateData(QString ID, QString name, QString value, QString source); void onGetData(QString ID, QString name, QString value, QString source); private: QSqlDatabase m_db; >; #endif // MYDB_H #include "mydb.h" MyDB::MyDB(QObject *parent) : QObject(parent) < m_db = QSqlDatabase::addDatabase("QSQLITE"); m_db.setConnectOptions(); m_db.setDatabaseName("D:/MySimulator/New Folder/TCPServer1/DB.db"); if (m_db.open())< qDebug() else < qDebug() QStringList tables = m_db.tables(); if (tables.contains("Presets", Qt::CaseInsensitive)) < qDebug() > void MyDB::onGetData(QString ID, QString name, QString value, QString source) < qDebug() else < qDebug("Empty Result"); >>else < qDebug("NO Result"); >> void MyDB::onUpdateData(QString ID, QString name, QString value, QString source) < qDebug() else < qDebug("NO Result"); >> #ifndef MYTHREAD_H #define MYTHREAD_H #include #include #include #include #include "Defn.h" #include "mydb.h" class MyThread : public QThread < Q_OBJECT public: explicit MyThread(int ID, MyDB* db, QObject * parent = 0); void run(); void parseInput(QString string); signals: void error(QTcpSocket::SocketError socketError); void updateData(QString ID, QString name, QString value, QString source); void getData(QString ID, QString name, QString value, QString source); public slots: void readyRead(); void disconnected(); void onDataAvailable(QString ID, QString name, QString value, QString source); private: QTcpSocket* socket; int socketDescriptor; MyDB* db; >; #endif // MYTHREAD_H #include "mythread.h" #include "qtcpserver.h" #include "qabstractsocket.h" MyThread::MyThread(int ID, MyDB* db, QObject * parent ): QThread(parent) < this->socketDescriptor = ID ; this->db = db; > void MyThread::run() < // thread starts here. qDebug() setSocketDescriptor(this->socketDescriptor))< emit error(socket->error()); return; > connect(socket, SIGNAL(readyRead()), this, SLOT(readyRead()), Qt::DirectConnection); connect(socket, SIGNAL(disconnected()), this, SLOT(disconnected()), Qt::DirectConnection); connect(this, SIGNAL(getData(QString, QString , QString , QString )), this->db, SLOT(onGetData(QString , QString , QString , QString ))); connect(this, SIGNAL(updateData(QString , QString , QString , QString )), this->db, SLOT(onUpdateData(QString , QString , QString , QString ))); connect(this->db, SIGNAL(dataAvailable(QString , QString , QString , QString )), this, SLOT(onDataAvailable(QString , QString , QString , QString ))); qDebug() void MyThread::readyRead() < QByteArray data = socket->readAll(); qDebug() void MyThread::disconnected() < qDebug() deleteLater(); exit(0); > void MyThread::parseInput(QString dataFromTCP) < qDebug() qDebug() QString strMessage = ""; for (int i = 0 ; i < list1.count() ; i++) < strMessage = list1[i]; QStringList list2 = strMessage.split(" ", QString::SkipEmptyParts); qDebug() qDebug() QString QString source = QString::number(socketDescriptor) ; if (list2[0] == "GET") < emit getData(ID, "", "", source); >else if (list2[0] == "UPD") < QString value = list2[2]; emit updateData(ID, "", value, source); >> > void MyThread::onDataAvailable(QString ID, QString name, QString value, QString source) < if( (QString::number(socketDescriptor) == source) || ("000" == source ) ) < qDebug() write(ba); > > #ifndef MYSERVER_H #define MYSERVER_H #include #include #include #include #include "mythread.h" #include "mydb.h" class MyServer: public QTcpServer < Q_OBJECT public: explicit MyServer(MyDB* pdb, QObject* parent = 0); void startServer(); signals: public slots: protected: void incomingConnection(qintptr socketDescriptor); private: MyDB* pdb ; >; #endif // MYSERVER_H #include "myserver.h" MyServer::MyServer(MyDB* pdb, QObject* parent ): QTcpServer(parent) < this->pdb = pdb; > void MyServer::startServer() < if (!this->listen(QHostAddress::Any, 1234))< qDebug() errorString(); > else < qDebug() > void MyServer::incomingConnection(qintptr socketDescriptor) < qDebug() start(); > Here the signal about which I mentioned above is dataAvailable from «mydb.cpp». If I comment out that line then server responds to client messages. But if that signal is emitted then after the initial response, the server seems to hang and no longer reacts to incoming messages from the client. The same code is working perfectly fine in mac and linux. But it is having this problem in Windows only. Could someone let me know what is it that I am doing wrong that it is failing only in Windows? Thanks in advance for helping me out.
EDIT:
- Be able to allow TCP connections from multiple clients simultaneously.
- If any client requests info, it gets the required data over the TCP connection.
- If any client updates info, all clients including the updating client, gets a notifications over the TCP connection.
Threading in C, cross platform
I am dealing with an existing project (in C) that is currently running on a single thread, and we would like to run on multiple platforms AND have multiple threads. Hopefully, there is a library for this, because, IMHO, the Win32 API is like poking yourself in the eye repeatedly. I know about Boost.Thread for C++, but, this must be C (and compilable on MinGW and gcc). Cygwin is not an option, sorry.
If you think that CreateThread is poking yourself in the eye repeatedly you should not be attempting this.
8 Answers 8
Try OpenMP API, it’s multi-platform and you can compile it with GCC.
Brief description from the wikipedia:
OpenMP (Open Multi-Processing) is an application programming interface (API) that supports multi-platform shared memory multiprocessing programming in C, C++, and Fortran,[3] on most platforms, processor architectures and operating systems, including Solaris, AIX, HP-UX, Linux, macOS, and Windows. It consists of a set of compiler directives, library routines, and environment variables that influence run-time behavior.
After over a year with OpenMP, I can assure everyone who reads this question that it is 100% worth the time.
I would use the POSIX thread API — pthread. This article has some hints for implementing it on Windows, and a header-file-only download (BSD license):
Edit: I used the sourceforge pthreads-win32 project in the past for multi-platform threading and it worked really nicely. Things have moved on since then and the above link seems more up-to-date, though I haven’t tried it. This answer assumes of course that pthreads are available on your non-Windows targets (for Mac / Linux I should think they are, probably even embedded)
Windows threading has sufficiently different functionality when compared to that of Linux such that perhaps you should consider two different implementations, at least if application performance could be an issue. On the other hand, simply implementing multi-threading may well make your app slower than it was before. Lets assume that performance is an issue and that multi-threading is the best option.
With Windows threads I’m specifically thinking of I/O Completion Ports (IOCPs) which allow implementing I/O-event driven threads that make the most efficient use of the hardware.
Many «classic» applications are constructed along one thread/one socket (/one user or similar) concept where the number of simultaneous sessions will be limited by the scheduler’s ability to handle large numbers of threads (>1000). The IOCP concept allows limiting the number of threads to the number of cores in your system which means that the scheduler will have very little to do. The threads will only execute when the IOCP releases them after an I/O event has occurred. The thread services the IOC, (typically) initiates a new I/O and returns to wait at the IOCP for the next completion. Before releasing a thread the IOCP will also provide the context of the completion such that the thread will «know» what processing context the IOC belongs to.
The IOCP concept completely does away with polling which is a great resource waster although «wait on multiple object» polling is somewhat of an improvement. The last time I looked Linux had nothing remotely like IOCPs so a Linux multi-threaded application would be constructed quite differently compared to a Windows app with IOCPs.
In really efficient IOCP apps there is a risk that so many IOs (or rather Outputs) are queued to the IO resource involved that the system runs out of non-paged memory to store them. Conversely, in really inefficient IOCP apps there is a risk that so many Inputs are queued (waiting to be serviced) that the non-paged memory is exhausted when trying to temporarily buffer them.