Richard Braakman wrote:
Hmm... if conn_destroy is being called in a context where it is still
possible that some other process has a lock on the connection, then
something is wrong. conn_destroy should only be called on connections
that are definitely not in use anymore.
The connection
Benjamin Lee wrote:
2002-02-18 05:15:28 [3] PANIC: gwlib/conn.c:174: unlock_out_real: Mutex unlock
failed. (Called from gwlib/conn.c:793:conn_register.)
This is probably the bug I mentioned a couple of weeks ago. As I said
before, it can be fixed by changing the order of the unlock
Andreas Fink wrote:
Has anyone yet resolved the problem we get in
gwlib/thread.c:mutex_unlock_real(), Andreas maybe?!
I wish I would. it still bytes me.
Does changing the order of the unlock_in() and unlock_out() statements
at the end of conn_register() in conn.c help? It fixes at least
Tuomas Luttinen wrote:
What limits the number of servers to 32? So is the an easy way to
increase it?
I would guess thats a limit of your operating system (check out ulimit).
Actually, that 32 is defined in the code: (http.c, line 1530)
enum { MAX_SERVERS = 32 };
This limit
Jacob Vennervald Madsen wrote:
When I use AT or CIMD2 as smsc and sepcify multiple recipients separated
by '+' in the http url, everything works just fine.
This multi-send feature is broken and should not be used. It doesn't
work correctly with any of the options that depend on or affect
