From 48ef7704c03e7e554c05de01bf8d1d70c16cb6f4 Mon Sep 17 00:00:00 2001
From: ProjectRevoTPP <projectrevotpp@hotmail.com>
Date: Wed, 20 Dec 2017 16:34:35 -0500
Subject: add libc building to agbcc.

---
 libc/stdlib/mlock.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 libc/stdlib/mlock.c

(limited to 'libc/stdlib/mlock.c')

diff --git a/libc/stdlib/mlock.c b/libc/stdlib/mlock.c
new file mode 100644
index 0000000..e7f7242
--- /dev/null
+++ b/libc/stdlib/mlock.c
@@ -0,0 +1,50 @@
+/*
+FUNCTION
+<<__malloc_lock>>, <<__malloc_unlock>>--lock malloc pool
+
+INDEX
+	__malloc_lock
+INDEX
+	__malloc_unlock
+
+ANSI_SYNOPSIS
+	#include <malloc.h>
+	void __malloc_lock (void *<[reent]>);
+	void __malloc_unlock (void *<[reent]>);
+
+TRAD_SYNOPSIS
+	void __malloc_lock(<[reent]>)
+	char *<[reent]>;
+
+	void __malloc_unlock(<[reent]>)
+	char *<[reent]>;
+
+DESCRIPTION
+The <<malloc>> family of routines call these functions when they need
+to lock the memory pool.  The version of these routines supplied in
+the library does not do anything.  If multiple threads of execution
+can call <<malloc>>, or if <<malloc>> can be called reentrantly, then
+you need to define your own versions of these functions in order to
+safely lock the memory pool during a call.  If you do not, the memory
+pool may become corrupted.
+
+A call to <<malloc>> may call <<__malloc_lock>> recursively; that is,
+the sequence of calls may go <<__malloc_lock>>, <<__malloc_lock>>,
+<<__malloc_unlock>>, <<__malloc_unlock>>.  Any implementation of these
+routines must be careful to avoid causing a thread to wait for a lock
+that it already holds.
+*/
+
+#include <malloc.h>
+
+void
+__malloc_lock (ptr)
+     struct _reent *ptr;
+{
+}
+
+void
+__malloc_unlock (ptr)
+     struct _reent *ptr;
+{
+}
-- 
cgit v1.2.3