From: <ra...@ra...> - 2010-10-27 16:24:18
|
Not having ever written to this list, I hadn't realized that I was not replying to the list. Sorry. As for a request for Windows API chops, I've got those, it's the SBCL internal knowledge I'm missing (and little pthreads knowledge). ----- Forwarded message from ----- Date: Tue, 26 Oct 2010 16:23:22 -0400 From: ra...@ra... Reply-To: ra...@ra... Subject: Re: [Sbcl-devel] Request for review of Windows threads support To: Kalyanov Dmitry <kal...@gm...> I tried it, and it didn't work for me, but I was doing something somewhat unusual. I was trying to write a CFFI for portaudio. Portaudio on Windows uses CreateThread, and uses that thread for callbacks to fill the audio buffers. I didn't do much tracking, but calling back into your version of a threaded Windows SBCL from an externally created thread was pretty unstable. It might work a couple times, then crash. Or it might crash the first time. Sometimes, I might get to run my function a few more times by initializing portaudio twice before calling anything else, which is pretty weird behavior. Neil Gilmore ra...@ra... |
From: Nikodemus S. <nik...@ra...> - 2010-10-27 21:10:57
|
On 27 October 2010 18:38, <ra...@ra...> wrote: > As for a request for Windows API chops, I've got those, it's the SBCL > internal knowledge I'm missing (and little pthreads knowledge). In addition to this list, #sb...@fr... may be a good place to get comments on the way SBCL does things. Everyone isn't there all the time, but pretty often _someone_ is. :) > I was trying to write a CFFI for portaudio. Portaudio on Windows uses > CreateThread, and uses that thread for callbacks to fill the audio > buffers. > > I didn't do much tracking, but calling back into your version of a > threaded Windows SBCL from an externally created thread was pretty > unstable. It might work a couple times, then crash. Or it might crash > the first time. As Dimitry noted, this isn't currently supported at all on SBCL on any platform. A complete solution would be to provide a way to do this -- basically creating sufficient context for the lisp thread in the callback. Not impossible, but a bit tricky. An easier workaround might be to have a C-side callback that sends a request to a Lisp thread to do the work and waits for the results. Cheers, -- Nikodemus |