I ran into the same issue. From my profiling it did indeed appear to have accumulated thousands of finalizers very quickly. I think I have that branch laying around somewhere. I could do some testing. It also caused segfaults for me. I did not have the time to pursue it at the time and I switched away from zmq, but I would love to go back to it.
On Nov 5, 2012 11:22 AM, "Moritz Heidkamp" <
address@hidden> wrote:
Hi Matt,
sorry for responding late, I'm a bit busy these days. However, as the
original author of the zmq egg I feel obliged to chime in :-)
Matt Welland <address@hidden> writes:
> However I need to ping servers to see if they are alive so I wrote a little
> code to try and connect to the server and return yay/nay. The problem I
> have is that if I don't close the socket (I'm pinging a number of servers)
> I get crashes.
That's pretty odd, maybe you're accumulating too many sockets before the
finalizers get a chance to run or something. Could you try to put a call
to (gc #t) into the loop? This should force finalizers to be run. I
would try it myself but your example program seems to have some
dependencies I'm not sure how to satisfy.
> If I do close the socket I get this:
>
> INFO: (0) connected as client
>
> Warning: in finalizer: (close-socket) Socket operation on non-socket:
> 88
I guess this could be considered a bug: The finalizer unconditionally
closes the socket which seems to lead to this error when it was
explicitly closed before. Skimming the API reference I don't see a way
to check whether a socket is already closed. Do you know of any? Or do
you have a better idea how to handle this situation?
Moritz
_______________________________________________
Chicken-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/chicken-users