Search Results

Search found 3 results on 1 pages for 'bstack'.

Page 1/1 | 1 

  • waiting for 2 different events in a single thread

    - by João Portela
    component A (in C++) - is blocked waiting for alarm signals (not relevant) and IO signals (1 udp socket). has one handler for each of these. component B (java) - has to receive the same information the component A udp socket receives. periodicaly gives instructions that should be sent through component A udp socket. How to join both components? it is strongly desirable that: the changes to attach component B to component A are minimal (its not my code and it is not very pleasent to mess with). the time taken by the new operations (usually communicating with component B) interfere very little with the usual processing time of component A - this means that if the operations are going to take a "some" time I would rather use a thread or something to do them. note: since component A receives udp packets more frequently that it has component B instructions to forward, if necessary, it can only forward the instructions (when available) from the IO handler. my initial ideia was to develop a component C (in C++) that would sit inside the component A code (is this called an adapter?) that when instanciated starts the java process and makes the necessary connections (that not so little overhead in the initialization is not a problem). It would have 2 stacks, one for the data to give component B (lets call it Bstack) and for the data to give component A (lets call it Astack). It would sit on its thread (lets call it new-thread) waiting for data to be available in Bstack to send it over udp, and listen on the udp socket to put data on the Astack. This means that the changes to component A are only: when it receives a new UDP packet put it on the Bstack, and if there is something on the Astack sent it over its UDP socket (I decided for this because this socket would only be used in the main thread). One of the problems is that I don't know how to wait for both of these events at the same time using only one thread. so my questions are: Do I really need to use the main thread to send the data over component A socket or can I do it from the new-thread? (I think the answer is no, but I'm not sure about race conditions on sockets) how to I wait for both events? boost::condition_variable or something similar seems the solution in the case of the stack and boost::asio::io_service io_service.run() seems like the thing to use for the socket. Is there any other alternative solution for this problem that I'm not aware of? Thanks for reading this long text but I really wanted you to understand the problem.

    Read the article

  • Encoding issue - 2nd band of ISO-8859-1 values do not get encoded?

    - by bstack
    Hello, I want to send the pound sign character i.e. '£' encoded as ISO-8859-1 across the wire. I perform this by doing the following: var _encoding = Encoding.GetEncoding("iso-8859-1"); var _requestContent = _encoding.GetBytes(requestContent); var _request = (HttpWebRequest)WebRequest.Create(target); _request.Headers[HttpRequestHeader.ContentEncoding] = _encoding.WebName; _request.Method = "POST"; _request.ContentType = "application/x-www-form-urlencoded; charset=iso-8859-1"; _request.ContentLength = _requestContent.Length; _requestStream = _request.GetRequestStream(); _requestStream.Write(_requestContent, 0, _requestContent.Length); _requestStream.Flush(); _requestStream.Close(); When I put a breakpoint at the target, I expect to receive the following: '%a3', however I receive '%u00a3' instead. ISO-8859-1 is divided into 2 groups of characters: (ref: http://en.wikipedia.org/wiki/ISO_8859-1) The lower range 20 to 7E - is where all characters seem to be encoded correctly The higher range A0 to FF - is where all characters seem to encode to their Unicode equivalent value As '£' is in higher range A0 to FF, it gets encoded to %u00a3. In fact when I use the first few characters of the higher range A0 to FF i.e. '¡¢£¤¥¦§¨©ª«¬®', I get '%u00a1%u00a2%u00a3%u00a4%u00a5%u00a6%u00a7%u00a8%u00a9%u00aa%u00ab%u00ac%u00ae'. This behaviour is consistent. The question I have is why do characters in the higher range A0 to FF get encoded to their unicode value - and not to their equivalent ISO-8859-1 value? Help would be greatly appreciated... Billy

    Read the article

1