Skip to content
This repository

Event loop integration #28

Open
jd opened this Issue December 31, 2012 · 9 comments

2 participants

Julien Danjou Marijn Haverbeke
Julien Danjou
jd commented December 31, 2012

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.

Marijn Haverbeke
Owner

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.

Julien Danjou
jd commented December 31, 2012

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.

Marijn Haverbeke
Owner

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.

Julien Danjou
jd commented January 02, 2013

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

Marijn Haverbeke
Owner

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

Julien Danjou
jd commented January 02, 2013

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.

Marijn Haverbeke
Owner

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.

Julien Danjou
jd commented January 02, 2013

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)?

Marijn Haverbeke
Owner

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.

Julien Danjou jd referenced this issue in orthecreedence/cl-async January 02, 2013
Closed

Allow changing blocking mode temporarily on socket/stream #51

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.