I'm need help with websocketspp / websockets++ please (https://github.com/zaphoyd/websocketpp).
I'm open to other simpler libraries, also C, if that's an overall better option :)
My overall goal is to have a websockets webpage as a replacement for a telnet client for DikuMUD.
I've been using the "echo_server" example which is running fine.
I'm trying to save the connection handler "hdl" from one callback and then re-use it later to send another message back to the client. Looks to me like hdl is a class that will get created / destroyed on the stack with each function call to e.g. on_message.
I would like to store the hdl somehow, e.g. in a std::map so that I can look it up and use that looked up hdl to send another message later to the same client.
Here's the example. Sorry for the void , I'm used to C and lightweight C++ :)
std::map<void *, void *> g_cMapHandler;
// Define a callback to handle incoming messages
void on_message(server* s, websocketpp::connection_hdl hdl, message_ptr msg)
{
void *myExample = 0; // A value I need to be able to retrieve
// Using &hdl here doesn't make sense, I presume hdl gets destroyed when on_message ends.
g_cMapHandler[&hdl] = myExample;
// But I can't figure out what really represents hdl? Maybe there a fd / file descriptor
// I can store somehow, and then how do I rebuild a hdl from it?
}
Thank you :-)
connection_hdl is istelf a pointer, store connection_hdl. It is a weak pointer.
Generally, suggest avoiding void* with asio, and using reference-counted smart pointers. Even though you can control lifetime of object in a synchronous program, and call free or delete when needed, in asynchronous program the flow is varying, so the right place to free pointer could be different place each time.
asio may use boost::weak_ptr or std::weak_ptr. boost one has operator <, so can be directly used in a map. For std, there's std::weak_ptr<T>::owner_before to be used for ordering, can be used via std::owner_less
std::map<websocketpp::connection_hdl, void *, std::owner_less<websocketpp::connection_hdl>> g_cMapHandler;
Related
I created a Rust wrapper for a C++ library for a camera using bindgen, and the camera handle in the C++ library is defined as typedef void camera_handle which bindgen ported over as:
pub type camera_handle = ::std::os::raw::c_void;
I'm able to successfully connect to the camera and take images, however I wanted to run code on a separate thread for temperature control of the camera, essentially changing the cooler power based on the current temperature of the camera, which I want to have run separately from the rest of the code. These calls require the camera handle, but when I spawn a new thread, I keep getting the error:
'*mut std::ffi::c_void' cannot be sent between threads safely
And underneath it, it mentions:
the trait 'std::marker::Send' is not implemented for '*mut std::ffi::c_void'
How can I send this to another thread so I can use this camera handle there as well? I have tried using fragile and send_wrapper, but have been unsuccessful with both of them.
Pointers do not implement Send or Sync since their safety escapes the compiler. You are intended to explicitly indicate when a pointer is safe to use across threads. This is typically done via a wrapper type that you implement Send and/or Sync on yourself:
struct CameraHandle(*mut c_void);
unsafe impl Send for CameraHandle {}
unsafe impl Sync for CameraHandle {}
Since implementing these traits manually is unsafe, you should be extra diligent to ensure that the types from the external library actually can be moved another thread (Send) and/or can be shared by multiple threads (Sync).
If you ever take advantage of the pointer's mutability without the protection of &mut self, it should probably not be Sync since having two &mut T at the same time is always unsound.
See:
Send and Sync in the Rustonomicon.
Can a struct containing a raw pointer implement Send and be FFI safe?
I am currently creating my own GUI-Library based on SFML.
At the moment i am working on a Button. So when creating a button you also have to specify a callback which is a function, executed on the button click.
Now, I'm answering me what the disadvantages are of using just a pointer to a function as a button-callback, because I don't know any popular GUI-Library doing it so simply, too.
If the callback function is a long process, I would execute it in a new thread, but i'm not sure about that in the moment.
So, what would be reasons, not to use such simple solution and especially, what would be a better way?
It's a tricky problem!
Function pointers are simple to implement on the sender side, but they are difficult to use on the receiver side because they they don't have any context.
One issue is that a function pointer cannot point to a member function. That's why you often see (C-style) frameworks pass an arbitrary void *userData to their callbacks, so you can cast your this pointer and retrieve it in that way. This still needs you to write a static wrapper function to cast the pointer back and call the member function.
A more modern solution would be to use std::function. This can contain a regular function pointer, a member function pointer, but also a lambda or a functor.
However, when you add context like this (or in some other way), you quickly run into difficulties with lifetimes. When the receiving class is destroyed before the sender, what is supposed to happen? If you don't do anything, this situation will result in undefined behaviour. A solution is to track on the receiver side to which events the receiver is subscribed, and unbind them before the receiver is destroyed. And this needs to be done in both directions: when the sender is destroyed, it also needs to notify the receiver that it should forget about the sender, otherwise the receiver would later try to unbind an event that no longer exists.
And I haven't even begun to think about multithreading yet...
There are libraries that solve these problems in various ways, for example eventpp (just found through a web search, this is not an endorsement).
Another one to mention would be the Qt toolkit, which went so far as to write their own small signals and slots extension to the C++ language (implemented as a code generator and a pile of macros) to solve this problem in a very ergonomical way.
what the disadvantages are of using just a pointer to a function as a button-callback
Passing some context argument to that function would come handy.
I mean, the UI may have a lot of buttons performing the same action on various objects. Think maybe of "send message" button next to each nick in a friend list.
So you may want your buttom to pass some context arguments to the call.
But since we're talking C++, this'd better be abstracted as
struct IButtonAction
{
virtual void OnAttached() = 0;
virtual void OnDetached() = 0;
virtual void OnClick() = 0;
};
And let the client code implement this interface storing whichever Arg1, Arg2, etc in each instance object.
The button class would call OnAttached/OnDetached when it begins/ends using the pointer to an instance of this callback interface. These calls must be paired. Client implementation of these methods may perform lifetime management and synchronization with OnClick, if required.
OnClick method performs the action.
I don't think the button should bother with threads. It's the responsibility of the client code to decide whether to spawn a thread for a lengthy action.
I've been learning how to send data to a program called FogLAMP https://github.com/foglamp/ and the data I want to send is asynchronous. My question is not about the foglamp code base itself, rather the below line of code.
I understand generally what the code is doing. But I do not know the exact mechanics in memory or the syntax for that matter.
I will do my best to describe what I believe is going on, but I am not entirely sure.
This is a code ingestion, so because the program is running two asynchronous threads, (the data collection and sending process (pid (1)) and the actual code set up as a daemon process (pid (2))) it is designed to allocate a void pointer (void * m_data) that will eventually be filled with a Reading object that should be sent to the cloud via process (1). This reading is produced, however, in process (2). So what I believe is going on is process (2) is producing a Reading object in memory so that process (1) can access that data.
I am lost when it comes to this line of code, though (I've included relevant code below to follow the execution path).
void (*m_ingest)(void *, Reading);
I haven't seen this syntax anywhere and I can't seem to describe this to google, so I'm not entirely sure what this means in C++.
I apologize I'm not able to provide much more information. I wasn't sure how to describe it, kind of like a cast to a type m_ingest (which is not a global variable or typedef).
I am looking through this code because I would like to implement the same thing into my own foglamp plugin using Robotic Operating Systems (ROS) as a multi threaded asynchronous data transfer to foglamp.
This is the code In question
void (*m_ingest)(void *, Reading);
void *m_data;
These two variables appear in the below functions (not entirely sure what (*cb)(void *, Reading) means either.
void OPCUA::registerIngest(void *data, void (*cb)(void *, Reading))
{
m_ingest = cb;
m_data = data;
}
/**
* Called when a data changed event is received. This calls back to the south service
* and adds the points to the readings queue to send.
*
* #param points The points in the reading we must create
*/
void OPCUA::ingest(vector<Datapoint *> points)
{
string asset = m_asset + points[0]->getName();
(*m_ingest)(m_data, Reading(asset, points));
}
The comment is very helpful, stating that ingest puts the array of Datapoint pointers into a queue to be sent to foglamp. It makes sense, what this s doing, but I would like a more robust explanation as to what is actually going on in memory.
The source code In question is found in the repository
https://github.com/foglamp/foglamp-south-opcua
Here is the source code
https://github.com/foglamp/foglamp-south-opcua/blob/develop/opcua.cpp
Here is the header file
https://github.com/foglamp/foglamp-south-opcua/blob/develop/include/opcua.h
Pretty basic c++ here. Thanks to #1201ProgramAlarm. It's just a function pointer. I read a quick tutorial here https://www.cprogramming.com/tutorial/function-pointers.html. But I now see that (*cb) is a function pointer passed through register_ingest to assign m_ingest to the same function as (*cb). Thus when foglamp needs data it accesses it through m_ingest. This function helps a lot
void plugin_register_ingest(PLUGIN_HANDLE *handle, INGEST_CB cb, void *data)
{
OPCUA *opcua = (OPCUA *)handle;
if (!handle)
throw new exception();
opcua->registerIngest(data, cb);
}
So INGEST_CB is a global callback function defined in some foglamp header file that then is assigned to the same address as m_ingest.
Humbling to learn something new in C++. I have never seen function pointers passed this way, only function addresses (i.e. through std::bind(&func, param)).
I’m trying to store an object passed from JavaScript to a Node.js Addon in a void *. I can’t seem to get this to compile; building with node-gyp produces error: no matching function for call to 'Cast'.
The long version of what I’m trying to do is write a Node.js Addon that runs Csound. Csound works, from a bird’s-eye view, with C functions that take a pointer to an opaque Csound struct as (usually) the first argument. This struct contains a void * to “hostData”, arbitrary data set by a program hosting Csound. Some things that Csound does, like posting messages, are modified with callbacks—function pointers in this case. I need a place to store callbacks for each instance of Csound, so I’m trying to let someone set hostData to an object from JavaScript, but I also want to set the callbacks for a Csound instance as hidden properties on this hostData object.
I think the code will need to look something like
#include "csound.h"
#include <node.h>
static void CsoundMessageCallback(CSOUND *Csound, int attributes,
const char *format, va_list valist)
{
// Call the JavaScript function we stored in the hostData of Csound.
}
static void _wrap_csoundSetMessageCallback(
const v8::FunctionCallbackInfo<v8::Value>& args)
{
v8::HandleScope scope(v8::Isolate::GetCurrent());
CSOUND *Csound;
// Pretend we get the Csound instance from args[0] here. This is actually done
// by SWIG <http://www.swig.org>.
// This does not compile. csoundGetHostData() returns a void *, but I’m assuming
// hostData was set to an object from JavaScript.
v8::Persistent<v8::Object> hostData =
v8::Persistent<v8::Object>::Cast(csoundGetHostData(Csound));
hostData.SetHiddenValue(
v8::String::New("CsoundMessageCallback"),
v8::Persistent<v8::Function>::Cast(args[1])
);
csoundSetMessageCallback(Csound, CsoundMessageCallback);
}
I’m guessing I need to take a close look at V8’s internal fields, but I’m really not sure.
Typically what I've done in situations like this is I write a wrapper C++ class (inheriting from node's ObjectWrap class) that stores a pointer to the instance of whatever C/C++ class I'm wrapping and has various public methods to interact with that instance.
When new is called from JS land, a new instance of the wrapper C++ class gets created and associated with the new JS object. Then you have JS functions that kick off whatever async tasks that utilize the wrapped library's callbacks.
From there it's just a matter of calling uv_async_send() from the wrapped library's callbacks to signal the main thread and then calling the JS callback from the uv_async callback.
You can see an example of all of this here (especially in the Windows-specific parts):
The Pcap class holds a pcap_t pointer (would be a CSOUND pointer for you).
When a new Pcap is created from JS land, I wrap a new C++ class instance.
Initialize a uv_async_t which sets up the callback to fire on uv_async_send() and also associates the user data pointer to the class instance for easy access. You could do this initialization during the call to new if you wanted, instead of a separate prototype function (open()) like I have done since initialization just happens once.
Then from the wrapped library's callback, I signal the main thread.
From the uv_async callback, I can then access the wrapper class instance and use V8 functions safely. Although in my particular case, I have another callback which uses V8 functions. However you can use them safely inside your uv_async callback.
As far as storing JS callbacks goes, there are different ways to handle that. One solution might be to create a baton object that stores a Persistent copy of the JS callback and the wrapper class instance and store that baton in uv_async_t's user data pointer. This would mean creating a new uv_async_t for every request (which is different than the example I gave above).
All thread create methods like pthread_create() or CreateThread() in Windows expect the caller to provide a pointer to the arg for the thread. Isn't this inherently unsafe?
This can work 'safely' only if the arg is in the heap, and then again creating a heap variable
adds to the overhead of cleaning the allocated memory up. If a stack variable is provided as the arg then the result is at best unpredictable.
This looks like a half-cooked solution to me, or am I missing some subtle aspect of the APIs?
Context.
Many C APIs provide an extra void * argument so that you can pass context through third party APIs. Typically you might pack some information into a struct and point this variable at the struct, so that when the thread initializes and begins executing it has more information than the particular function that its started with. There's no necessity to keep this information at the location given. For instance you might have several fields that tell the newly created thread what it will be working on, and where it can find the data it will need. Furthermore there's no requirement that the void * actually be used as a pointer, its a typeless argument with the most appropriate width on a given architecture (pointer width), that anything can be made available to the new thread. For instance you might pass an int directly if sizeof(int) <= sizeof(void *): (void *)3.
As a related example of this style: A FUSE filesystem I'm currently working on starts by opening a filesystem instance, say struct MyFS. When running FUSE in multithreaded mode, threads arrive onto a series of FUSE-defined calls for handling open, read, stat, etc. Naturally these can have no advance knowledge of the actual specifics of my filesystem, so this is passed in the fuse_main function void * argument intended for this purpose. struct MyFS *blah = myfs_init(); fuse_main(..., blah);. Now when the threads arrive at the FUSE calls mentioned above, the void * received is converted back into struct MyFS * so that the call can be handled within the context of the intended MyFS instance.
Isn't this inherently unsafe?
No. It is a pointer. Since you (as the developer) have created both the function that will be executed by the thread and the argument that will be passed to the thread you are in full control. Remember this is a C API (not a C++ one) so it is as safe as you can get.
This can work 'safely' only if the arg is in the heap,
No. It is safe as long as its lifespan in the parent thread is as long as the lifetime that it can be used in the child thread. There are many ways to make sure that it lives long enough.
and then again creating a heap variable adds to the overhead of cleaning the allocated memory up.
Seriously. That's an argument? Since this is basically how it is done for all threads unless you are passing something much more simple like an integer (see below).
If a stack variable is provided as the arg then the result is at best unpredictable.
Its as predictable as you (the developer) make it. You created both the thread and the argument. It is your responsibility to make sure that the lifetime of the argument is appropriate. Nobody said it would be easy.
This looks like a half-cooked solution to me, or am i missing some subtle aspects of the APIs?
You are missing that this is the most basic of threading API. It is designed to be as flexible as possible so that safer systems can be developed with as few strings as possible. So we now hove boost::threads which if I guess is build on-top of these basic threading facilities but provide a much safer and easier to use infrastructure (but at some extra cost).
If you want RAW unfettered speed and flexibility use the C API (with some danger).
If you want a slightly safer use a higher level API like boost:thread (but slightly more costly)
Thread specific storage with no dynamic allocation (Example)
#include <pthread.h>
#include <iostream>
struct ThreadData
{
// Stuff for my thread.
};
ThreadData threadData[5];
extern "C" void* threadStart(void* data);
void* threadStart(void* data)
{
intptr_t id = reinterpret_cast<intptr_t>(data);
ThreadData& tData = threadData[id];
// Do Stuff
return NULL;
}
int main()
{
for(intptr_t loop = 0;loop < 5; ++loop)
{
pthread_t threadInfo; // Not good just makes the example quick to write.
pthread_create(&threadInfo, NULL, threadStart, reinterpret_cast<void*>(loop));
}
// You should wait here for threads to finish before exiting.
}
Allocation on the heap does not add a lot of overhead.
Besides the heap and the stack, global variable space is another option. Also, it's possible to use a stack frame that will last as long as the child thread. Consider, for example, local variables of main.
I favor putting the arguments to the thread in the same structure as the pthread_t object itself. So wherever you put the pthread record, put its arguments as well. Problem solved :v) .
This is a common idiom in all C programs that use function pointers, not just for creating threads.
Think about it. Suppose your function void f(void (*fn)()) simply calls into another function. There's very little you can actually do with that. Typically a function pointer has to operate on some data. Passing in that data as a parameter is a clean way to accomplish this, without, say, the use of global variables. Since the function f() doesn't know what the purpose of that data might be, it uses the ever-generic void * parameter, and relies on you the programmer to make sense of it.
If you're more comfortable with thinking in terms of object-oriented programming, you can also think of it like calling a method on a class. In this analogy, the function pointer is the method and the extra void * parameter is the equivalent of what C++ would call the this pointer: it provides you some instance variables to operate on.
The pointer is a pointer to the data that you intend to use in the function. Windows style APIs require that you give them a static or global function.
Often this is a pointer to the class you are intending to use a pointer to this or pThis if you will and the intention is that you will delete the pThis after the ending of the thread.
Its a very procedural approach, however it has a very big advantage which is often overlooked, the CreateThread C style API is binary compatible so that when you wrap this API with a C++ class (or almost any other language) you can do this actually do this. If the parameter was typed, you wouldn't be able to access this from another language as easily.
So yes, this is unsafe but there's a good reason for it.