From: Nikodemus S. <nik...@ra...> - 2014-10-22 14:16:59
|
Tomas tried to respond, but got rejected as his email address was not subscribed. (It is possible he is subscribed with some other email address, but I don't see tom...@kn... in the subscriber list.) ...though on this occasion it is kind of fortunate it was rejected, because serve-event is definitely still there, as APROPOS would tell you. :) ...that said I agree recommendation of iolib. Serve-event style recursive event loop is unloved for a good reason. On the surface of it it is very clever and nice design, but when you think more about it you realize how it is kind of fundamentally awkward. (Some would say broken, not sure I'd go that far.) ...and it being unloved is the reason it hasn't been properly documented despite still being there. We don't want to encourage people to use it, but support it for legacy code. (Or something in that direction. If someone were to document it nicely I'd be happy to merge such a patch.) (Sorry about top-posting, answering in a rush from gmail.) On 22 October 2014 14:07, Tomas Hlavaty <tom...@kn...> wrote: > Hi, > > do I need to do something special > in order to be allowed to post to this mailing list? > > Thank you, > > Tomas > > On 22/10/14 12:51, sbc...@li... wrote: > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner ats...@li.... > > > > Re: [Sbcl-help] serve-events.eml > Subject: > Re: [Sbcl-help] serve-events > From: > Tomas Hlavaty <tom...@kn...> > <tom...@kn...> > Date: > 22/10/14 12:32 > To: > sbc...@li... > > Hi FAU, > > serve event thing was removed from sbcl during > the cmucl fork iirc. > > You could try iolib (see<http://src.knowledgetools.de/tomas/winapi/index.html> <http://src.knowledgetools.de/tomas/winapi/index.html> > for windows port) > or write something yourself using ffi, > but unless you really know and accept where > that path leads to, I would strongly advice against it. > It would make your code unportable and completely incompatible > with anything else. > > I would recommend using threads and writing simple, > readable code:-) > > Cheers, > > Tomas > > On 22/10/14 11:34, FAU wrote: > > > I think I was not specific enough. I'm looking to find a way to do> multiplexing IO. I basically want to monitor two inputs (network> sockets) if either has data available then I'd consume it but the read> operation must not block if the data block requested can not be filled.> In the C world it could be done with select() and non-blocking read().>> I think this is not possible with standard CL. As you pointed out iolib> seems to be a solution for that (on Linux). However I need something> that works on Windows too. If that would be sbcl only then that is fine> with me (it's just a toy project).>> On Tue, 2014-10-21 at 19:40 -0200, Diogo F. S. Ramos wrote: > > >>>> Couldn't find much information on it. Seems to be a way to do>>>> non-blocking IO in sbcl?>>>>>>>> Does anybody have a working example up the sleeve? > > >>> Not that I might have a satisfying answer for you, but just as I>>> understand what you want.>>>>>> By "non-blocking IO" you mean (read-char stream) will not block if there>>> is not something to be read? (when (listen stream) (read-char>>> stream)) would be acceptable? > > >> Oh, and I overlooked `read-char-no-hang'. > > >>> ------------------------------------------------------------------------------> Comprehensive Server Monitoring with Site24x7.> Monitor 10 servers for $9/Month.> Get alerted through email, SMS, voice calls or mobile push notifications.> Take corrective actions from your mobile device.> http://p.sf.net/sfu/Zoho> _______________________________________________> Sbcl-help mailing list> Sbc...@li...> https://lists.sourceforge.net/lists/listinfo/sbcl-help > > > |
From: Tomas H. <tom...@kn...> - 2014-10-22 14:42:45
|
Hi Nikodemus, On 22/10/14 16:16, Nikodemus Siivola wrote: > Tomas tried to respond, but got rejected as his email address was not > subscribed. (It is possible he is subscribed with some other email > address, but I don't see >> tom...@kn... <mailto:tom...@kn...> >> > in the subscriber list.) > thanks for forwarding the message to the list. I should be subscribed now. I wonder, how did I get sbcl-help emails to this email address without being subscribed:-) > ...though on this occasion it is kind of fortunate it was rejected, > because serve-event is definitely still there, as APROPOS would tell > you. :) Ah, thank you for the correction. Cheers, Tomas |
From: FAU <fa...@ri...> - 2014-10-22 19:02:49
|
Thanks for the tip for the iolib port. I'll have a look at it. You are right about the thread model. That's what I'm doing atm and it works fine. Blocking then is not really an issue here (but read on). The following is not really sbcl specific but maybe somebody has an idea how to solve this otherwise you can ignore this. I now have the problem to gracefully shutdown a thread. My initial idea was to have a pipe from the control thread into the worker thread and closing the pipe in the control thread would then shutdown the worker (on his own terms) but then again I'm back to do multiplexing between two sockets. On Wed, 2014-10-22 at 16:42 +0200, Tomas Hlavaty wrote: > Hi Nikodemus, > > On 22/10/14 16:16, Nikodemus Siivola wrote: > > Tomas tried to respond, but got rejected as his email address was not > > subscribed. (It is possible he is subscribed with some other email > > address, but I don't see > >> tom...@kn... <mailto:tom...@kn...> > >> > > in the subscriber list.) > > > > thanks for forwarding the message to the list. I should be subscribed > now. I wonder, how did I get sbcl-help emails to this email address > without being subscribed:-) > > > ...though on this occasion it is kind of fortunate it was rejected, > > because serve-event is definitely still there, as APROPOS would tell > > you. :) > > Ah, thank you for the correction. > > Cheers, > > Tomas > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ Sbcl-help mailing list Sbc...@li... https://lists.sourceforge.net/lists/listinfo/sbcl-help |
From: Tomas H. <tom...@kn...> - 2014-10-23 11:34:40
|
Hi FAU, On 22/10/14 21:02, FAU wrote: > The following is not really sbcl specific but maybe somebody has an idea > how to solve this otherwise you can ignore this. I now have the problem > to gracefully shutdown a thread. My initial idea was to have a pipe > from the control thread into the worker thread and closing the pipe in > the control thread would then shutdown the worker (on his own terms) but > then again I'm back to do multiplexing between two sockets. threads shut down gracefully when the thread lambda returns. You can simply create a thread for whatever needs to be done, and when it's done, the thread will end. I think hunchentoot does this, instead of trying to be clever about reusing threads. If you are reusing threads and have a loop inside the thread lambda, sb-concurrency offers some useful constructs for this use-case. Other important aspect is timeouts on IO operations, which ccl has but sbcl not (yet) <https://bugs.launchpad.net/sbcl/+bug/721452>. Cheers, Tomas |