xavi/libweb/server.c, branch v0.4.0Small and lightweight web framework written in C99 and POSIX.1-2008.
https://gitea.privatedns.org/xavi/libweb/atom?h=v0.4.02024-08-22T00:27:34+00:00Move signal handling to processes2024-08-22T00:27:34+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2024-08-19T22:07:05+00:00urn:sha1:43e89fb23943b5ffb6854f290592c29cd079bf46
So far, libweb installed a signal handler so as to handle SIGTERM,
SIGPIPE and SIGINT signals so that processes would not have to care
about such details.
However, it is not advisable for libraries to install signal handlers,
as signals are handled on a per-process basis. The previous approach
would be incompatible if several instances of the library were allocated
by the same process.
Unfortunately, this has the undesired side effect of adding the
boilerplate code into the process.
server.c: Fix wrong priority for do_exit2024-01-20T00:19:57+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2024-01-20T00:09:18+00:00urn:sha1:91ff743df9fcee048cb44dba0c7047df04454dd2
Under some specific circumstances, poll(2) would return a positive
integer, but do_exit might had been previously set. This caused libweb
to ignore SIGTERM, with the potential risk for an endless loop.
Merge pull request 'Fix double-free on failed `server_client_close`' (#2) from midokura-xavi/libweb:fix-double-free into master2023-11-20T15:27:28+00:00xavixavi@noreply.localhost2023-11-20T15:27:28+00:00urn:sha1:8f1ad3124e9e063ca0ee7c2548c747b20de3529d
Reviewed-on: https://gitea.privatedns.org/xavi/libweb/pulls/2
Fix double-free on failed server_client_close2023-11-20T15:25:58+00:00Xavier Del Campoxavier.delcampo@midokura.com2023-11-20T11:20:51+00:00urn:sha1:59a67a7541ee1559b140494c21a25b195246a4fa
Even if server_client_close fails, it is needed for client_free to
remove the dangling reference from h->clients.
Split handler_loop from handler_listen2023-11-20T15:06:19+00:00Xavier Del Campoxavier.delcampo@midokura.com2023-11-16T11:23:08+00:00urn:sha1:98f5f52461b0c1ab1ee3331722bd32e2db9e1d41
Some applications might set up a struct handler object to listen on any
port i.e., 0, but still need a way to determine which port number was
eventually selected by the implementation.
Therefore, handler_listen has been reduced to the server initialization
bit, whereas the main loop has been split into its own function, namely
handler_loop.
Because of these changes, it no longer made sense for libweb to write
the selected port to standard output, as this is something now
applications can do on their own.
Rename project from slweb to libweb2023-10-10T22:07:13+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-10-10T21:21:35+00:00urn:sha1:0222b75e8554796548e079aa3393c512ae30ac24
It was found out there was another project of the same name around
(https://git.sr.ht/~strahinja/slweb/), also related to website
generation.
In order to avoid confusion, a new name has been chosen for this
project. Surprisingly, libweb was not in use by any distributions
(according to https://repology.org and AUR index), and it should
reflect well the intention behind this project i.e., being a library
to build web-related stuff.
server.c: Replace sequential calls with loop2023-10-10T21:16:11+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-10-10T21:16:11+00:00urn:sha1:832e198f8c77970b5b923eb18201ba83d9c72b80server.c: Fix build on FreeBSD2023-09-26T20:58:11+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-09-26T20:58:11+00:00urn:sha1:8b39bc5db98c252269fe526a8c411bf245770ba2Move header files to subdirectory2023-07-20T23:28:38+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-07-20T21:47:33+00:00urn:sha1:8c3ba33ced08b211db0cd5f81675bdf62f55acc7
Since slweb is meant as a library, it is advisable to keep public header
files under their own directory in order to avoid name clashing i.e.,
#include "something.h"
Now becomes:
#include "slweb/something.h"
server.c: Fix typo2023-07-20T21:52:55+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-07-05T22:42:12+00:00urn:sha1:01cebe5917c6f3cdca0e13f7b681bb0d6867bb75