Re: Update: "Bogus Handlers" error using the WIRE package: where should error handling condition be applied?

On 3/2/07, Suresh Madhu <[email protected]> wrote:
> The following message is a courtesy copy of an article
> that has been posted to gmane.lisp.cmucl.general as well.
>
>
>  [Not sure if I'm subscribed, please CC the list if it doesn't make it
>   there]
>
> * "Denis Papathanasiou" <e4044eb40703010751r5becd90amcb991a8b57df6bcd@XXX> :
> | The past few days, we turned all the client processes off, and the
> | error still occurred inside the server process, so it had nothing to
> | do with WIRE.
> |
> | But since the server process is doing vanilla I/O on the local
> | filesystem -- using (with-open-file) -- to read and write files it
> | owns (there's also plenty of disk space), I'm not sure what the "bogus
> | handlers" message means exactly.
>
> Bogus handlers IIRC are handlers attached to closed FDs.
>
> I have not used the WIRE package (but do use TCP/IP on top of the MP
> package -- i.e. having a CMUCL MP:PROCESS doing a listen, and another
> to handle each connection.)
>
> The WIRE package does not use MP but uses fd-handlers.  I noticed you

Ah, thanks for that clarification; we'd not been able to connect the
dots between bogus handlers and WIRE.

> used an MP function in your code.  I'd guess your bogus handler
> messages are from some little tested interaction between MP and the
> FD-HANDLERS packages.  Perhaps you can eliminate the MP:PROCESS and
> see if you still get the messages?

It's plausible to try it in the interim, to find out whether or not
that is indeed causing the error, but not using MP in the server
creates more problems than it solves.

I.e., in a single-threaded mode, when (reload) is busy, none of the
public methods in the server process will be responsive enough when
they're invoked by any of the client processes.

Perhaps we should dump WIRE and switch to a model like what you use
("use TCP/IP on top of the MP package -- i.e. having a CMUCL
MP:PROCESS doing a listen, and another to handle each connection.").

Do you have any examples/code snippets of that that you could share?

> | I've looked for references to explain this message, but couldn't find
> | any. Could anyone point me to an explanation, or help me understand
> | what is happening?
> |
> | And as part of that, does anyone know whether or not the function I
> | mentioned earlier -- (clear-bogus-handlers) -- would clear that error,
> | assuming I put it as a condition in the right place in my server code?
>
> [CLEAR-BOGUS-HANDLERS looks like trebuchet (my taste), and not
> appropriate in this case, perhaps you can consider wrapping your code
> inside a HANDLER-BIND that uses INVOKE-RESTART.]

This may sound like a dumb question -- I really need to go back and
study conditions again -- but if CMUCL is offering a restart that
solves the problem ("REMOVE-THEM"), then if I were to wrap a
handler-bind/invoke-restart (where the restart is "REMOVE-THEM") in
the right place in the server code, then I can go on using WIRE and
MP, correct?

I.e. I know this condition will occur infrequently, but I also know
how to recover from it, right?