<g-gundam>
I'd like to give each hunchentoot worker thread its own mito db connection, but I'm not sure how to run a function before every HTTP request. Can anyone advise?
manwithluck has quit [Ping timeout: 276 seconds]
<veqq>
Out of curiosity, how'd you inherit the service? You work in a company using CL or?
JuanDaugherty has joined #commonlisp
<g-gundam>
veqq: Yeah, got a CL job, and it's my first time using CL.
<veqq>
Wow! Quite a few people must envy you!
<g-gundam>
I wasn't even looking for work. I was just helping someone with some elisp, and them someone else chimed in to ask if I wanted work.
<veqq>
Unfortunately, I don't do much web/networking stuff and can't directly help. I might be able to suggest a way to run a func before requests, but... Could you contextualize how those requests are happening?
* JuanDaugherty
doesn, i'd rather do cl (and other langs i like) as a free worker
<veqq>
g-gundam: Or rather... What's wrong with the macro advice in the answer you posted? Just replace the func calls with a macro which "prepares" everything by giving the threads their own cons?
<g-gundam>
veqq: I'm not familiar enough with hunchentoot to know where I can put that so that it would happen for every request.
<g-gundam>
I'd like to follow that advice, but don't know where to put it.
<JuanDaugherty>
hunchentoot is pretty simple
<JuanDaugherty>
haven used in a while but iirc request processing is quite clearly and cleanly delimited
<JuanDaugherty>
assuming it hasn significantly changed in a decade or so which is a good bet
<g-gundam>
server definition looks like this: (setf *server* (make-instance 'easy-routes:easy-routes-acceptor :port port))
<g-gundam>
then there's a bunch of defroutes for each route.
<JuanDaugherty>
oh yeah the easy pkg that hides everything
<veqq>
g-gundam: (defclass db-aware-acceptor (hunchentoot:easy-acceptor) ()) and then... stuff?
<JuanDaugherty>
you might not wanna use that in ur case
<veqq>
Easy routes is there instead so... It might already implement the logic somewhere
<JuanDaugherty>
actually that is one thing i tweak from time time
<veqq>
might-> it certinly does
<JuanDaugherty>
the code running the easy pkg
<g-gundam>
veqq: I might have to make my own acceptor. I wasn't sure I wanted to go there (being a CL noob).
<veqq>
It'd probably just be 3-4 lines, maybe, hopefully
<veqq>
Like/instead of the stackover flow thing, just use progn (like scheme begin) to put the thread preperation logic before whatever you actually want to do
JuanDaugherty has quit [Quit: praxis.meansofproduction.biz (juan@acm.org)]
kniffy has quit [Quit: zzzz]
<|3b|>
or a method on hunchentoot:start-thread (probably lightly more modification of the actual app to do that cleanly)
triffid has quit [Read error: Connection reset by peer]
anticomputer has quit [Read error: Connection reset by peer]
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #commonlisp
triffid has joined #commonlisp
anticomputer has joined #commonlisp
decweb has quit [Quit: Konversation terminated!]
Lord_of_Life has quit [Ping timeout: 265 seconds]
kniffy has joined #commonlisp
<veqq>
g-gundam: tagging incase you didn't notice
<g-gundam>
veqq: ...the actual make-thread call is deep in the guts of hunchentoot. I don't know if I can manipualte *default-special-bindings* in the right way at the right time.
<g-gundam>
keep in mind, i'm still kinda new to CL.
<g-gundam>
Thanks for the ping though.
<|3b|>
you can set it globally
<veqq>
g-gundam: names in asterics are globals
<veqq>
so you can just set it anywhere
<g-gundam>
is that part of the language? (the asterisk thing)
<g-gundam>
or is it convention?
<|3b|>
no, they are "specials", which is sort of like globals, but might also be thread-local
<|3b|>
** is convention
<veqq>
convention
<|3b|>
but a particular name being a "special variable" is part of the language, which is done with declarations (usually automatically by DEFVAR or DEFPARAMETER)
<|3b|>
and the convention is there so you don't accidentally get a special variable where you expected a lexical
<|3b|>
(and the distinction between global and thread-local/dynamic-binding is important, because that's the problem that we are trying to solve in the first place from what i understood of the link)
<g-gundam>
yes, i need thread-local db connections.
stanrifkin_ has joined #commonlisp
stanrifkin has quit [Ping timeout: 252 seconds]
Lord_of_Life has joined #commonlisp
tam has left #commonlisp [deuces]
shka has joined #commonlisp
asarch has joined #commonlisp
edgar-rft` has joined #commonlisp
edgar-rft has quit [Ping timeout: 252 seconds]
asarch has quit [Quit: Leaving]
admich1 has joined #commonlisp
admich1 has quit [Read error: Connection reset by peer]
admich1 has joined #commonlisp
<kagevf>
g-gundam: maybe you can put an AROUND method on tbnl:handle-request ... something like:
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #commonlisp
bjorkintosh has quit [Changing host]
bjorkintosh has joined #commonlisp
ingeniot has quit [Ping timeout: 252 seconds]
King_julian has joined #commonlisp
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
bjorkintosh has quit [Changing host]
King_julian has quit [Ping timeout: 248 seconds]
McParen has quit [Remote host closed the connection]
kevingal has joined #commonlisp
wbooze has quit [Quit: Leaving]
ewig` has quit [Read error: Connection reset by peer]
ewig` has joined #commonlisp
ingeniot has joined #commonlisp
ewig` has quit [Ping timeout: 252 seconds]
wbooze has joined #commonlisp
chomwitt has joined #commonlisp
ingeniot has quit [Ping timeout: 245 seconds]
yitzi has joined #commonlisp
ingeniot has joined #commonlisp
kevingal has quit [Ping timeout: 268 seconds]
ewig` has joined #commonlisp
leeb_ has joined #commonlisp
leeb has quit [Ping timeout: 260 seconds]
iNomad has quit [Quit: leaving]
lcn_2 has quit [Ping timeout: 248 seconds]
Noisytoot has quit [Excess Flood]
Noisytoot has joined #commonlisp
Noisytoot has quit [Remote host closed the connection]
Noisytoot has joined #commonlisp
<soweli_iki>
is the `continue' restart provided by `assert' only meant to be invoked interactively? i'm overlooking how to provide values for `PLACES'
ingeniot has quit [Ping timeout: 252 seconds]
wbooze has quit [Quit: Leaving]
ewig` has quit [Ping timeout: 244 seconds]
rgherdt has quit [Quit: ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.1)]
<semz>
the details of ASSERT's CONTINUE restart are mostly up to the implementation afaik
<soweli_iki>
maybe i'm just misunderstanding the restart system; that's an area i could use more experience. i have something like (let ((x 0)) (handler-case (assert (> x 2) (x)) (t () (compute-restarts)))) and the result is a list with only an ABORT restart
phantomics has joined #commonlisp
<beach>
soweli_iki: You will probably need HANDLER-BIND rather than HANDLER-CASE.
<soweli_iki>
is the proper form something like this? (handler-bind ((t #'(lambda (c) (compute-restarts c)))) (let ...))
<soweli_iki>
aha, i think i see my mistake. reading a little more closely the CLHS page for `handler-bind' reveals that the handler is expected to perform a non-local control transfer to interrupt the normal condition handling flow
admich1 has quit [Ping timeout: 252 seconds]
<soweli_iki>
thanks beach! that got me unstuck
ingeniot has joined #commonlisp
admich1 has joined #commonlisp
lcn_2 has joined #commonlisp
admich1 has quit [Read error: Connection reset by peer]