You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, mxqd forks a reaper process for every user job which stays around until the user job is done. This has several problems:
To avoid the child from interfering with the sql server, the parent calls mysql_close() before the fork and mysql_connect() after. This generates unnecessary load on the mysql server. And the semantics are not well defined in the mysql documentation. We can not be sure that, that (all) sockets are closed and are not being leaked to the child, which would be a security problem in itself and might create new problems when the internal workings of the libraries are changed (e.g. in atexit() handlers).
Although the reaper calls mysql_library_end before exit, valgrind still shows unfreed memory (mysql->openssl). This in itself is not a problem, but a further hint, that the behavior of the library with cloned address spaces is unclear.
While a long-running reaper exists, any memory which mxqd modifies, needs to be duplicated. At the same time, any memory it frees still needs physical memory in the reaper. This is even true if mxqd is re-execed. So we needlessly sit on physical memory.
Maybe we should use exec() for the reaper processes to avoid unclear library semantics and memory duplication.
The text was updated successfully, but these errors were encountered:
Currently, mxqd forks a reaper process for every user job which stays around until the user job is done. This has several problems:
Maybe we should use exec() for the reaper processes to avoid unclear library semantics and memory duplication.
The text was updated successfully, but these errors were encountered: