Hi Marcel, Why do you think that you have some race condition? You are using single thread, unlikely it could produce any internal race condition.
With recent versions of MHD, I suggest to use MHD_USE_AUTO.
In your case it could be MHD_USE_AUTO | MHD_USE_INTERNAL_POLLING_THREAD
| MHD_USE_DEBUG combination.
'daemon->connections_tail' should be NULL while MHD do not serve any
connection (only listening).
I suggest you to try to debug 'MHD_accept_connection ()' - this function
should accept new connection.
Alternatively, you could try to run any of provided examples to ensure
that MHD function properly.
--
Best Wishes,
Evgeny Grin
22.01.2018 1:09, Marcel Rutten пишет:
> Thanks, Silvio, it would be great if you could send me that working
> code. Probably saves a lot of time :-). My environment is an
> openembedded tree, as published by the manufacturer of the thermostat,
> back in 2012. Parts of it are really old, so sometimes I have to do
> quite some patching to backport newer code to that tree and toolchain.
> Nevertheless, your working code is probably fairly easy to build.
> libmicrohttpd wasn't so hard in terms of passing it through this
> toolchain. Getting it to work is a different story :-).
>
> In the meantime, I ploughed through a lot of routines, working my way
> up from the routines that have daemon->default_handler (which is
> called from ozwcp) as argument.
> I have tested the following options for the server:
>
> MHD_USE_EPOLL | MHD_USE_INTERNAL_POLLING_THREAD | MHD_USE_DEBUG
>
> This ends up in a race condition in MHD_epoll(), as called in
> MHD_polling_thread().
>
> MHD_USE_POLL | MHD_USE_INTERNAL_POLLING_THREAD | MHD_USE_DEBUG
>
> gives a race condition in MHD_poll()
>
> and finally:
> |
> MHD_USE_INTERNAL_POLLING_THREAD | MHD_USE_DEBUG
> This gives a race condition in MHD_select(). The race conditions at
> least explain why the client keeps trying, while nothing gets actually
> loaded. Only after killing the daemon, the connection is reset. I did
> some follow-up on the race condition in MHD_select(), and found that
> the connections in the daemon struct are not filled:
> (excerpt from internal_run_from_select() ):
> ... (FD_ISSET (ds, read_fd_set)) ) (void) MHD_accept_connection
> (daemon); if (0 == (daemon->options & MHD_USE_THREAD_PER_CONNECTION))
> { /* do not have a thread per connection, process all connections now
> */ prev = daemon->connections_tail; <---- prev = 0x00 while (NULL !=
> (pos = prev)) <---- pos is also 0x00, so the loop never starts,
> resulting in a new call to MHD_select(), and so on and on .. { prev =
> pos->prev; ds = pos->socket_fd; ...
> Both current and previous connections are NULL pointers, which is not
> good :-(, but it already narrows the issue down to a much smaller part
> of the daemon. So the next question is: where are these connections
> filled, and how do I check if it's done properly?
> |
>
> On 21 January 2018 at 22:28, silvioprog <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hello Marcel, welcome to the list!
>
> I used MHD on ARM in a small HTTP server testing for
> Android:
> https://lists.gnu.org/archive/html/libmicrohttpd/2017-02/msg00014.html
> <https://lists.gnu.org/archive/html/libmicrohttpd/2017-02/msg00014.html>
> . This link contains an attached picture showing the results. I
> think I have the sources in my old machine.
>
> I don't know if my environment can be useful for you, but I built
> MHD for ARM via integrated Android Studio's CMake, and used MHD in
> Java project with JNI. I can search and send sources if they could
> be useful for you ...
>
> On Sun, Jan 21, 2018 at 7:48 AM, Marcel Rutten
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi, I'm new to this list, and I have been trying to get
> libmicrohttpd to work on a linux-based smart thermostat.
>
> To no avail, so far. I should say that I'm not an expert on
> web connections, but fairly fluent in C.
>
> The thermostat has a Freescale imx 27 processor, (ARM-926 EJS)
> and has an openembedded image, developed around 2011, with
> linux kernel 2.6.26. The reason I want to get libmicrohttpd
> working on it, is because it features a zwave controller,
> which may be used to control TRVs (Thermostatic Radiator
> Valves), a feature which is not available in the standard
> firmware of the thermostat. The zwave interface can be
> operated through openzwave, and its web interface ozwcp (open
> zwave control panel). ozwcp is linked against libmicrohttpd to
> provide the web interface.
>
> I have tested the combination libopenzwave-1.4.164,
> libmicrohttpd-0.9.58 and ozwcp (latest version from github) on
> a CentOS7 machine, x86_64, with a USB zwave controller and it
> works flawlessly. External access to the webinterface is OK.
>
> I built the same libraries and code for the thermostat, and
> everything works, apart from the web interface. When testing
> with wireshark, I can send a request, and get a 0-byte
> ACKnowledgement. For the rest, the server remains quiet. No
> 404 not found, forbidden, unable to connect, nothing. There
> appears to be no timeout for external connections, in fact, my
> PC has been trying to connect for the last 30 minutes or so,
> without interruption. The thermostat has no firewall (I
> switched it off), and nmap shows the default port (8090) to be
> open.
>
> I have built libmicrohttpd with the following options :
> "--prefix=/usr/local/ --disable-dependency-tracking
> --enable-examples --enable-messages --enable-https
> --enable-largefile --enable-curl --with-pic", copied from
> archlinux for ARM.
>
> The main program was linked against this library, and the
> webserver is started normally, at least does not report any
> errors. The options were set as follows:
> MHD_USE_THREAD_PER_CONNECTION |
> MHD_USE_INTERNAL_POLLING_THREAD | MHD_USE_DEBUG |
> MHD_USE_ERROR_LOG
>
> I browsed through previous threads of this mailing list, and
> the only thing I came across regarding ARM-specific issues was
> the definition of a long vs. a long long integer. There are
> differences between a long on x86_64 (8 bytes) and ARM (4
> bytes length). I'm not sure if this plays a role, Other than
> that' there's nothing much to find.
>
> My questions: Is this something new, or have other people
> encountered this problem, and if so, how was it solved.
> If it's really a new issue, where do I start looking? The code
> is well documented, but it's a lot to plough through.
>
> TIA,
>
> marcelr
>
>
> --
> Silvio Clécio
>
>
signature.asc
Description: OpenPGP digital signature
