Event loop integration

[jd]

I'd like to use postmodern, and therefore a PG connection, into an event loop such as cl-async. To do that, I see 2 ways:

• Allow one to retrieve the socket from the database-connection class so the file descriptor can be retrieved and passed to cl-async (not the preferred way I'd say)
• Allow one to initiate the connection and pass the created socket to cl-postgres so it uses it directly (probabaly the best way). One could also provide a function rather than a socket, to recreate the socket in case of a disconnection for example.

[marijnh]

What makes you think the first approach is not preferred? It seems simpler (not burdening client code with initiating the actual connection), and quite harmless.

[jd]

I think it'll be trickier, because getting the file descriptor for a connection requires implementation specific code depending on the type of socket you're using, etc. Furthermore, the reconnection case can be tricky to handle too.

That's why the second approach seems easier to me.

[marijnh]

Since usocket doesn't provide a way to get a file descriptor from a socket (or a socket from a file descriptor), it seems there's going to be some unportable code anyway. At least, I don't see a way around it. My scheme would require the client code to deliver whatever CL-Postgres uses as a socket on that implementation, and to handle reconnects you'd just make sure to fetch the current file descriptor from the connection right before you wait on it. If it's broken, then it'll immediately be returned, and control will be passed to CL-Postgres, which will handle the reconnect, do something, and then return to your loop so that you can wait on it again.

[jd]

It seems possible to retrieve a fd from a socket, see orthecreedence/cl-async#41 (comment)

[marijnh]

Surely it's possible, but not portably (the code there only has cases for four implementations).

[jd]

Ah, sure, sorry your sentence wasn't clear in this regard. :)

That's why I though my second proposal was better, it's way more portable in the sense portability doesn't depends on cl-postgres, but on the user. But IIUC, this is also what you end up proposing.

I've already managed to do this successfully with cl-irc and cl-async, by providing a stream from cl-async to cl-irc. By default cl-irc uses usocket that it transforms into a stream.

[marijnh]

Your second proposal has the same problem though -- if you give CL-Postgres a raw file descriptor, it'll have to wrap it itself (using lots of #+ cases). If you give it a socket object, you'll have to do the special-casing yourself.

[jd]

My second proposal doesn't talk about a raw file descriptor, but a socket. Maybe even a stream might work and would be better (higher level)?

[marijnh]

It looks like the socket slot in a connection object can be any kind of stream, so I guess that would work. If you submit a patch implementing it (second proposal), I'll happily merge it. Please take a moment to consider the situation when using ssl. I think it should 'just work', as long as the stream has some underlying file descriptor for cl+ssl to work with, but there might be complications.

[sabracrolleton]

JD, is this still an issue for you?

[jd]

@sabracrolleton It's not an active issue anymore but the problem might still exist AFAIK.