Lost filedescriptors due to race while threading

I'm running Roxen 6.0+ with Pike 8.0 using my new pgsql driver.
This has been running stable in three production environments for the past
two weeks.

However...
I now have an instance where:
There is no error message in the roxen debug log.
I had three database connections open (at some point), filedescriptors
16, 24 and 25.

Now I notice that pgsql is waiting on a mutex which waits for input from
filedescriptor 16.
Filedescriptor 16 sits in its normal idle position waiting for input
(in its own thread).
However, looking at the status of filedescriptor 16 (in the roxen active
filedescriptors list), it shows that it is *listening* on some port (52994).

I never listen on that port though.

lsof shows filedescriptors 16,24 and 25 in the following state:
roxen     17290 32083     root   16u     sock                0,5      0t0   83594815 can't identify protocol
roxen     17290 32083     root   24u     IPv4           83423009      0t0        TCP foo.bar:52952->db.foo:postgresql (ESTABLISHED)
roxen     17290 32083     root   25u     IPv4           83423011      0t0        TCP foo.bar:52953->db.foo:postgresql (ESTABLISHED)

Does that mean that I missed some sort of close callback?
Because I *have* a close callback active on the filedescriptor
which does a forced Stdio.File.close() on the object; normally
I would expect this to fire the read callback too (which would then
automatically dissolve the mutexes I'm waiting for).
Or do I need to manually trigger the read callback after closing
the descriptor?
-- 
Stephen.