I'm not gonna post any real code here, because it's a part of a complex code base, but I'll ask anyway just in case somebody find this issue familiar:
I create a boost::asio::io_service and run it in a boost::thread.
Then I use boost::asio::udp::socket::async_receive_from() to wait for incoming packet.
The call looks like this:
udpSocket.async_receive_from(
inDataBuffer,
udpEndpoint,
boost::bind( &Node::handleReceiveFrom, this,
boost::asio::placeholders::error,
boost::asio::placeholders::bytes_transferred
)
The signature of handleReceiveFrom() is this:
void Node::handleReceiveFrom( const boost::system::error_code& errc, size_t bytesRecvd )
Inside handleReceiveFrom(), I access the inDataBuffer passed to async_receive_from() and read bytesRecvd bytes from it. But sometimes when the packets arrive really fast, the bytesRecvd value refers to the size of the packet before the one that's actually found in the inDataBuffer.
Precisely, the packet whose size is found in bytesRecvd never actually appears in inDataBuffer, at least not as fat as handleReceiveFrom() can see, and instead, the data of the next packet is in the inDataBuffer by the time handleReceiveFrom() gets a chance to look at it.
I thought the problem was that I was somehow calling async_receive_from() from two different threads but after some testing, that doesn't seem to be the case.
Apart from that, I'm at a loss what could be going on here.
I would very much appreciate any thought on this!
I didn't find the root cause of the problem but I solved it by using the synchronous Asio receive function instead of the asynchronous one. In other words, I ditched boost::asio::udp::socket::async_receive_from() and replaced it with boost::asio::udp::socket::receive_from() run in a separate thread.
This way, I actually implemented what I thought asio was doing when I called async_receive_from(). But apparently, there's something inside that routine that works in a different way than I'd expect.
Still, this solution works like a charm, so I'm declaring my previous question closed.
Related
I'm practicing with the vulkan API, Yesterday I wasted almost the entire day in implementing secondary buffers for use different fragment shaders on different objects.
Big issue was an error "segmentation fault" in call to vkCmdDrawIndexed(). For the moment this is a matt black box for me, I don't find a method to investigate the origin of the issue. Although the vulkan API has validation layers for debug, it is already complicate without these ones. I suspect that the error is in the code for the creation secondary CommandBuffers.
Leaving out these problems due to my not knowing, I accidentally found that the code works the same with only the primary commandbuffer and multiple calls to vkCmdBindPipeline():
vkBeginCommandBuffer(primaryCommandBuffer...);
vkCmdBeginRenderPass(...);
vkCmdBindPipeline(...pipeline_things_a);
vkCmdBindDescriptorSets(...);
vkCmdBindVertexBuffers(...);
vkCmdBindIndexBuffer(...);
vkCmdSetViewport(...);
vkCmdSetScissor(...);
draw_things_a(...) {... vkCmdDrawIndexed(...) ...}
vkCmdBindPipeline(...pipeline_things_b);
vkCmdBindDescriptorSets(...);
vkCmdBindVertexBuffers(...);
vkCmdBindIndexBuffer(...);
vkCmdSetViewport(...);
vkCmdSetScissor(...);
draw_things_b(...) {... vkCmdDrawIndexed(...) ...}
vkCmdEndRenderPass(primaryCommandBuffer);
vkEndCommandBuffer(primaryCommandBuffer);
I'm outside regular learning path, so my question can be an obvious error for the most, but I ask:
Is it an error the multiple call of vkCmdBindPipeline() in primary command buffer?
No, that's not an error. You can do arbitrary calls for e.g. binding pipelines within a single command buffer. In general you can call all commands beginning with vkCmd arbitrarily in a single command buffer as much as you want.
I need to serialize a function in Erlang, send it over to another note, deserialize and execute it there. The problem I am having is with files. If the function reads from a file which is not in the second node I am getting an error. Is there a way how I can differentiate between serializable and not serializable constructs in Erlang? Thus if a function makes use of a file or pid, then it fails to serialize?
Thanks
First of all, if you are sending anonymous functions, be extremely careful with that. Or, rather, just don't do it
There are a couple of cases when this function won't even be executed or will be executed in a completely wrong way.
Every function in Erlang, even an anonymous one, belongs to some module, in the one it's been constructed inside, to be precise. If this function has been built in REPL, it's bound to erl_eval module, which is even more dangerous (I'll explain further, why).
Say, you start two nodes, one of them has a module named 'foo', and one doesn't have such a module loaded (and cannot load it). If you construct a lambda inside the module 'foo', send it to the second node and try to call it, you'll fail with {error, undef}.
There can be another funny problem. Try to make two versions of module 'foo', implement a 'bar' function inside each of them and implement a lambda inside of which (but the lambdas will be different). You'll get yet another error when trying to call a sent lambda.
I think, there could possibly be other tricky parts of sending lambdas to different nodes, but trust me, that's already quite a lot.
Secondly, there are tons of way you can get a process or a port inside a lambda without knowing it in advance
Even though there is a way of catching closured variables from a lambda (if you take a look at a binarized lambda, all the external variables that are being used inside it are listed starting from the 2nd byte), they are not the only source of potential pids or ports.
Consider an easy example: you call a self() function inside your lambda. What will it return? Right, a pid. Okay, we can probably parse the binary and catch this function call, along with a dozen of other built-in functions. But what will you do when you are calling some external function? ets:lookup(sometable, somekey)? some_module:some_function_that_returns_god_knows_what()? You don't know what they are going to return.
Now, to what you can actually do here
When working with files, always send filenames, not descriptors. If you need file's position or something, send it as well. File descriptors shouldn't be known outside the process they've been opened.
As I mentioned, do everything to avoid lambdas to be sent to other nodes. It's hard to tell how to avoid that, since I don't know your exact task. Maybe, you can send a list of functions to execute, like:
[{module1, parse_query},
{module1, dispatch_parsed_query},
{module2, validate_response},
{module2, serialize_query}]
and pass arguments through this functions sequence (be sure all the modules exist everywhere). Maybe, you can actually stick to some module that is going to be frequently changed and deployed over the entire cluster. Maybe, you might want to switch to JS/Lua and use externally started ports (Riak is using spidermonkey to process JS-written lambdas for Map/Reduce requests). Finally, you can actually get module's object code, send it over to another node and load it there. Just keep in mind it's not safe too. You can break some running processes, lose some constructed lambdas, and so on.
My questions are:
Is there a way to conclusively determine if a function is async-signal-safe if you don't have access to its implementation?
If not, is there a way to test if function would be async-signal-safe enough to call from a signal handler?
If you reads the man pages of signal() or sigaction(), you get a list of async-signal-safe functions (functions that can be safely called inside a signal handler). However, I believe that this list is not exhaustive. For example, the following page http://linux.die.net/man/7/signal, under the Async-signal-safe functions header, reads:
POSIX.1-2004 (also known as POSIX.1-2001 Technical Corrigendum 2) requires an implementation to guarantee that the following functions can be safely called inside a signal handler:
And then it proceeds to list the normal async-signal-safe functions listed in the man pages above. As I read it, it says "it requires", not "these are the only ones".
For example, this site says that back_trace_symbols_fd() is async-signal safe. That function obtains is data from dladdr() and it doesn't use malloc() like back_trace_symbols(), so it looks like it may be safe. Also, I did some testing, and the output struct of dladdr() contains char* variables, but these are NOT malloc'ed at runtime. The char string they point to exists at run-time even before dladdr() is called.
Any thoughts or ideas that can point me in the right direction are appreciated.
If you don't have access to the function's implementation, you can look at the manual page. If the manual page doesn't say it is async-safe, and the POSIX standard doesn't say it is async-safe, the only safe conclusion is "it is not async-safe" (coupled with "do not use it").
There is no 100% reliable way to test whether a function is async-safe. Remember, testing can only show the presence of bugs, not their absence (Dijkstra). The mere fact that you don't manage to tickle the function into misbehaving under test may simply mean that your testing is not adequate (but rest assured, the important customer who you can't afford to offend will immediately and accidentally devise a devastatingly effective test that demonstrates that the function is not async-safe almost as soon as you release the code with the faulty assumption).
What are you hoping to achieve in the signal handler? You should consider whether it is the right place for it. It is probably best to follow the advice of the man page:
In general, signal handlers should do little more
than set a flag; most other actions are not safe.
So let's say I have a C API that looks like this:
// configure various parameters
int set_option(const char* name, const char* value);
// callback invoked during long running operation
typedef int (*callback_t)(void* whatever);
// start a long running operation
int some_long_operation(callback_t callback);
These functions are documented as not being reentrant. Should I attempt to enforce this (e.g. by setting a flag somewhere and returning an appropriate error code) or should I just write if off as undefined behavior? Most of the code I've seen does not attempt to do this; I'm just wondering if that's a conscious decision or if it's just pragmatism (or perhaps laziness). It seems to me that if you wanted to write really robust code you might try something like this; on the other hand, if you're not following the documentation then maybe all bets should be off.
As a member of a team responsible for maintaining a SDK, my experience has been scary at times. Granted our documentation is not great, but I have seen some pretty strange things in OEM support requests. A good number of those stem from calling functions in the context of a callback invoked by another function. Most of these are documented as being not supported, but we don't have any code in place to prevent it; in fact, most instances of this will appear to work but some may actually trash our internal state. It just seems like sometimes it might be easier to enforce proper API usage rather than rely on people to read the documentation.
What is the closest you can get to a try-catch block in php4?
I'm in the middle of a callback during an xmlrpc request and it's required to return a specifically structured array no matter what.
I have to error check all accesses to external resources, resulting in a deep stack of nested if-else blocks, ugly.
Late answer, I realise, sorry. I hope this is still relevant for you:
First, I'm echoing the comments your got in response to your post. PHP5 is the way to go.
However:
I'm in the middle of a callback during
an xmlrpc request and it's required to
return a specifically structured array
no matter what.
If you can vouch for that the program cannot possibly continue without getting a structured array back, and you absolutely have to work with PHP4, then an exit() or die() with detailed error information will get you much the same effect as a fatal exception would.
That's far removed from being graceful, of course. If you want something catchable, then return values and if-checking the result are your best bet, unfortunately. There are some standard ways of passing back specific error objects, but it's still the same thing - return the error object, if-check whether the result was an error object, react.
Still, take a look at PEAR's error object.