Writing a Windows Service in Common Lisp
Francisco Vides =??B?RmVybsOhbmRleg==?=
I need to develop a piece of code which will run on Windows machines, doing
some bidirectional RPC with a central server. I won't need any user
interface, the software will run as a service. Since I don't have much
experience developing on such platform, I'm seriously considering to use
Common Lisp for such task.
This is my question: can you recommend me any Common Lisp implementation for
Windows that can assist me in this task. A plus would be a link to some
documentation. I'd rather use a free implementation, but a commercial one is
also ok.
After some googling I found that Franz has something about it, I downloaded
id and will give it a try. Is there some other way to accomplish.
Thanks in advance!
+-----------------
| Francisco Vides Fernández <fvi...@dedaloingenieros.com>
| Director técnico.
| Dédalo Ingenieros http://www.dedaloingenieros.com/
| PGP: http://pgp.rediris.es:11371/pks/lookup?op=index&search=0xB1299C15
+------
blandest
<fvi...@dedaloingenieros.com> wrote:
> Dear Lispers
>
> I need to develop a piece of code which will run on Windows machines, doing
> some bidirectional RPC with a central server. I won't need any user
> interface, the software will run as a service. Since I don't have much
> experience developing on such platform, I'm seriously considering to use
> Common Lisp for such task.
>
> This is my question: can you recommend me any Common Lisp implementation for
> Windows that can assist me in this task. A plus would be a link to some
> documentation. I'd rather use a free implementation, but a commercial one is
> also ok.
>
> After some googling I found that Franz has something about it, I downloaded
> id and will give it a try. Is there some other way to accomplish.
>
> Thanks in advance!
>
> +-----------------
> | Francisco Vides Fernández <fvi...@dedaloingenieros.com>
> | Director técnico.
It depends on your needs. A stand alone (command line) application
that will be executed using the Windows Scheduling Tasks service
(under any user that you like) may be enough.
I don't see why people usually choose the more complicated "Windows
Services" way instead of writing a simple program. The only concern is
that this service must run without any users logged on and should stay
"hidden" (no annoying console/gui window). You can accomplish this
using the solution mentioned above.
Francisco Vides =??B?RmVybsOhbmRleg==?=
> On Jan 31, 12:21 am, Francisco Vides =??B?RmVybsOhbmRleg==?=
> <fvi...@dedaloingenieros.com> wrote:
>> Dear Lispers
>>
>> I need to develop a piece of code which will run on Windows machines,
>> doing some bidirectional RPC with a central server. I won't need any user
>> interface, the software will run as a service. Since I don't have much
>> experience developing on such platform, I'm seriously considering to use
>> Common Lisp for such task.
> It depends on your needs. A stand alone (command line) application
> that will be executed using the Windows Scheduling Tasks service
> (under any user that you like) may be enough.
>
> I don't see why people usually choose the more complicated "Windows
> Services" way instead of writing a simple program. The only concern is
> that this service must run without any users logged on and should stay
> "hidden" (no annoying console/gui window). You can accomplish this
> using the solution mentioned above.
Excuse my ignorance on windows (I'm a long time Linux user) but Windows
Scheduling sounds more like cron, it will execute the program at certain
times. I need a process started when the machine boots (I don't care if
there's an user logged or not) and keeps executing in background until the
machine is powered off. So it looks me like a service. Am I wrong?
And, again, can I do it with some Common Lisp implementation (other than
Allegro, which I've already found)
Thanks
+-----------------
| Francisco Vides Fernández <fvi...@dedaloingenieros.com>
| Director técnico.
| Dédalo Ingenieros http://www.dedaloingenieros.com/
Pascal J. Bourguignon
> blandest wrote:
>
>> On Jan 31, 12:21 am, Francisco Vides =??B?RmVybsOhbmRleg==?=
>> <fvi...@dedaloingenieros.com> wrote:
>>> Dear Lispers
>>>
>>> I need to develop a piece of code which will run on Windows machines,
>>> doing some bidirectional RPC with a central server. I won't need any user
>>> interface, the software will run as a service. Since I don't have much
>>> experience developing on such platform, I'm seriously considering to use
>>> Common Lisp for such task.
> [...]
> And, again, can I do it with some Common Lisp implementation (other than
> Allegro, which I've already found)
clisp works well on MS-Windows.
http://clisp.cons.org/
But if you need to do bidirectional RPC at the same time, you may need
a multi-threaded implementation, which case it's a little too soon for
clisp. But I'm not sure sbcl can do threads on MS-Windows yet either.
--
__Pascal Bourguignon__
blandest
<fvi...@dedaloingenieros.com> wrote:
> blandest wrote:
> > On Jan 31, 12:21 am, Francisco Vides =??B?RmVybsOhbmRleg==?=
> > <fvi...@dedaloingenieros.com> wrote:
> >> Dear Lispers
>
> >> I need to develop a piece of code which will run on Windows machines,
> >> doing some bidirectional RPC with a central server. I won't need any user
> >> interface, the software will run as a service. Since I don't have much
> >> experience developing on such platform, I'm seriously considering to use
> >> Common Lisp for such task.
> > It depends on your needs. A stand alone (command line) application
> > that will be executed using the Windows Scheduling Tasks service
> > (under any user that you like) may be enough.
>
> > I don't see why people usually choose the more complicated "Windows
> > Services" way instead of writing a simple program. The only concern is
> > that this service must run without any users logged on and should stay
> > "hidden" (no annoying console/gui window). You can accomplish this
> > using the solution mentioned above.
>
> Excuse my ignorance on windows (I'm a long time Linux user) but Windows
> Scheduling sounds more like cron, it will execute the program at certain
> times.
Yes, but it will execute on boot too (see schtasks.exe on Windows XP/
2003).
> I need a process started when the machine boots (I don't care if
> there's an user logged or not) and keeps executing in background until the
> machine is powered off. So it looks me like a service. Am I wrong?
The problem with Windows services is that they are harder to maintain
than a simple console application.
I've seen the Allegro API and it looks a little bit too complicated
for what you need (but maybe I've misunderstood your intention ...).
At work, my team is currently maintaining such a service (written in
C# .Net). We don't send custom control commands to this service (only
the standard start/stop). The advantage of simple application is that
you can easily test it using the command line (and your user account).
As far as I know that is impossible with a Windows Service. Also, you
won't depend on some specific implementation that happens to implement
the required API (such as Allegro).
> And, again, can I do it with some Common Lisp implementation (other than
> Allegro, which I've already found)
>
> Thanks
>
> +-----------------
> | Francisco Vides Fernández <fvi...@dedaloingenieros.com>
> | Director técnico.
> | Dédalo Ingenieroshttp://www.dedaloingenieros.com/
George Neuner
It's more than that. A Windows service that does any significant
processing usually must be multithreaded because there are time limits
for responding to service manager requests - if the program is busy
and doesn't reply, the service manager may kill it.
That said, a lot can be done with a single thread and non-blocking
I/O. If the problem can be solved by overlapped I/O, a single thread
may be fine.
If the OP has access to Visual Studio, it can generate the framework
of a .NET service in C#. There are also native service program
frameworks in C and C++ buried in the Windows SDK. The OP could then
embed ECL or Guile or whatever in the framework. That would solve the
threading problem if necessary - the thread could be started by the
framework and run the embedded Lisp.
George
Francisco Vides =??B?RmVybsOhbmRleg==?=
>> Excuse my ignorance on windows (I'm a long time Linux user) but Windows
>> Scheduling sounds more like cron, it will execute the program at certain
>> times.
>
> Yes, but it will execute on boot too (see schtasks.exe on Windows XP/
> 2003).
Then this could be the way to go. Many thanks for your help!
+-----------------
| Francisco Vides Fernández <fvi...@dedaloingenieros.com>
| Director técnico.
| Dédalo Ingenieros http://www.dedaloingenieros.com/
Francisco Vides =??B?RmVybsOhbmRleg==?=
>>But if you need to do bidirectional RPC at the same time, you may need
>>a multi-threaded implementation, which case it's a little too soon for
>>clisp. But I'm not sure sbcl can do threads on MS-Windows yet either.
>
> It's more than that. A Windows service that does any significant
> processing usually must be multithreaded because there are time limits
> for responding to service manager requests - if the program is busy
> and doesn't reply, the service manager may kill it.
I will need multithreading since there could me simultaneous incoming
requests.
> That said, a lot can be done with a single thread and non-blocking
> I/O. If the problem can be solved by overlapped I/O, a single thread
> may be fine.
>
> If the OP has access to Visual Studio, it can generate the framework
> of a .NET service in C#. There are also native service program
> frameworks in C and C++ buried in the Windows SDK. The OP could then
> embed ECL or Guile or whatever in the framework. That would solve the
> threading problem if necessary - the thread could be started by the
> framework and run the embedded Lisp.
Many thanks for all your suggestions!
Alex Mizrahi
there is a simple util called srvany -- it installs itself
as a service and then launches your application when service
starts.
Jerome Baum
<fvi...@dedaloingenieros.com> writes:
> I will need multithreading since there could me simultaneous incoming
> requests.
Just a FYI, you don't. You can use non-blocking I/O to accept
connections, by using the backlogging features of the sockets
implementation. You should use that anyway.
Of course, more connections than the backlog allows will always
be a problem, even if you multithread.
George Neuner
<fvi...@dedaloingenieros.com> wrote:
>George Neuner wrote:
>
>>>But if you need to do bidirectional RPC at the same time, you may need
>>>a multi-threaded implementation, which case it's a little too soon for
>>>clisp. But I'm not sure sbcl can do threads on MS-Windows yet either.
>>
>> It's more than that. A Windows service that does any significant
>> processing usually must be multithreaded because there are time limits
>> for responding to service manager requests - if the program is busy
>> and doesn't reply, the service manager may kill it.
>
>I will need multithreading since there could me simultaneous incoming
>requests.
Simultaneous I/O requests are not necessarily a reason for
multithreading ... whether you need threads depends more on how many
requests you expect and how much CPU work must be done to service each
one. With asynchronous I/O, the I/O itself doesn't count as work.
Do you know about the 'select' function in _nix? Do you know how to
handle multiple sockets (or files) using it?
Windows calls its asynchronous I/O "overlapped" and it works a bit
differently from 'select', but the result is the same ... you start an
I/O operation and go do something else while it happens. Windows
tells you it's finished by signaling a user provided event (per I/O
call if you like).
You can do quite a lot with asynchronous I/O and a single thread.
It's usually relatively easy to program a state model by breaking up
non-trivial request processing into explicit steps, tracking the
progress of each request, and looping through the active requests
performing the next step when necessary.
You may think "why do that when I have real OS threads"? Well, OS
threads have not inconsiderable overhead, both in scheduling cycles
and memory. For high activity server processes, it is frequently more
efficient to handle all the I/O with one thread and use pool threads
if necessary for heavy computing tasks. You can always add a new I/O
thread if the existing ones are saturated.
If you go the thread-per-request route, a heavily loaded server runs
the risk of hitting process or system limits, running out of address
space (at least on 32-bit), thrashing, etc. In general, with a server
process, I think it's preferable to keep the number of OS threads
involved to a minimum.
[I'm sure someone else here will tell you the exact opposite. Where
people stand on this issue depends on their background ... mine is
operating systems, embedded, real time and high availability (24/7,
uptime in months) applications. Lots of web programmers see no wrong
in using OS threads. I say "use them sparingly". I do support
"green" threading (user space threads) as an alternative to explicit
state models if a decent package is available. I haven't been very
impressed with green threading in any Lisp I've yet seen.]
Anyway, the normal model of a Windows service is a main thread that
responds to Service Manager requests and one or more worker threads
that do the actual job of the program. All the threads need to be
coordinated so the Service Manager is aware of the program's status
and can control it. I haven't seen what Lispworks or Allegro have in
the way of Window service frameworks, but if you embed some Lisp into
a C based service framework I think you'll be better off keeping the
number of threads to a minimum.
George
Alex Mizrahi
GN> handle multiple sockets (or files) using it?
Windows has `select` too
Russell McManus
George Neuner <gneu...@comcast.net> writes:
> In general, with a server process, I think it's preferable to keep
> the number of OS threads involved to a minimum.
I think this is generally correct but a useful extension of the idea
is to pick the number of your threads in some ratio to the number of
CPUs on the box. E.g. if you have an 8 cpu box, then 1 thread is
leaving most of the box idle. Also >1000 threads is likely not
optimal, due to scheduling overhead.
Probably 8-16 threads is optimal. Profile, profile, profile, then
choose.
-russ
George Neuner
Yes, but Windows select() _only_ works with sockets. _nix select()
also works with files.
You can mix using sockets and files (and pipes and mailboxes) in
Windows but you have to do it with WaitMultipleEvent().
George
George Neuner
I agree. My response to the OP was kind of knee-jerk ... but a lot of
people reach for threads as a first resort rather than analyzing the
problem and deciding whether (and how many) threads are really needed.
George
Mark Wooding
> E.g. if you have an 8 cpu box, then 1 thread is leaving most of the
> box idle.
Rather than `idle', I'd say `free for other processes'. If you're
expecting that your server is the only thing running on the machine, and
you can make use of the extra processors then go for it.
-- [mdw]
Francisco Vides =??B?RmVybsOhbmRleg==?=
> I'm sure someone else here will tell you the exact opposite. Where
> people stand on this issue depends on their background ... mine is
> operating systems, embedded, real time and high availability (24/7,
> uptime in months) applications. Lots of web programmers see no wrong
> in using OS threads.
Yeah! Your answer made some os-related-long-unused neural connections blink
again, and I thank you for that (good food for thought) :)
That said, the problem I'm solving:
* won't have a high number of requests
* each request will simply add a new job to a queue to be resolved by an
human agent, and this will take a long time (hours, maybe days), so high
response rate is not a problem.
So, to keep things simple, I'll stick to the threads based solution.
Of course I understand that with other kind of requirements (real time, for
example) I would be forced to use other kind of solutions.
Many thanks
MasterZiv
<fvi...@dedaloingenieros.com> wrote:
> I will need multithreading since there could me simultaneous incoming
> requests.
In this case, you have too little to choose from.
Only two CL implementations run multi threading, OpenMCL and SBCL.
Only one is available on Win32, it is SBCL, but SBCL on Win32 still
does NOT
support unix-like SELECT, even then it is supported in Win32 for TCP
sockets.
So I would recommend thinking twice before going this way.
On Unix/linux, LISP is a king, on Win32 things are not that good.
I myself had to switch to linux only to continue development in lisp.
Zach Beane
> On Jan 31, 10:15 pm, Francisco Vides =??B?RmVybsOhbmRleg==?=
> <fvi...@dedaloingenieros.com> wrote:
>
>> I will need multithreading since there could me simultaneous incoming
>> requests.
>
> In this case, you have too little to choose from.
> Only two CL implementations run multi threading, OpenMCL and SBCL.
Not true. Corman Lisp, Allegro Common Lisp, and LispWorks Common Lisp
all support threads on Windows.
Zach
Raffael Cavallaro
> Not true. Corman Lisp, Allegro Common Lisp, and LispWorks Common Lisp
> all support threads on Windows.
Right, but with LispWorks for example only one thread can be running in
the lisp at a time. Others that are pure foreign calls might run
concurrently but you can't have two *lisp* threads running concurrently
on a multi core machine. So even though LispWorks uses native threads,
those native threads won't use multiple cores if those threads are
running lisp code.
--
Raffael Cavallaro, Ph.D.
Marco Antoniotti
<raffaelcavall...@pas.espam.s.il.vous.plait.mac.com> wrote:
> On 2009-02-02 19:55:49 -0500, Zach Beane <x...@xach.com> said:
>
> > Not true. Corman Lisp, Allegro Common Lisp, and LispWorks Common Lisp
> > all support threads on Windows.
>
> Right, but with LispWorks for example only one thread can be running in
> the lisp at a time. Others that are pure foreign calls might run
> concurrently but you can't have two *lisp* threads running concurrently
> on a multi core machine. So even though LispWorks uses native threads,
> those native threads won't use multiple cores if those threads are
> running lisp code.
I guess I should just dig in lisp-hug, but isn't this LW limitation
only for MacOS?
Cheers
--
Marco
Espen Vestre
> I guess I should just dig in lisp-hug, but isn't this LW limitation
> only for MacOS?
No, you're mixing it up with a quite different limitation of the mac
implementation: That all windows run in a common thread.
--
(espen)
Pascal Costanza
LispWorks 6.0 will not only have removed that limitation, but will
actually introduce support for running threads on different cores.
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Raffael Cavallaro
> LispWorks 6.0 will not only have removed that limitation, but will
> actually introduce support for running threads on different cores.
Unfortunately it's not here yet.
--
Raffael Cavallaro, Ph.D.
Raffael Cavallaro
> I guess I should just dig in lisp-hug, but isn't this LW limitation
> only for MacOS?
<http://www.lispworks.com/documentation/lw51/LWUG/html/lwuser-238.htm>
"16.5.1 Native threads on Windows, Mac OS X, Linux and FreeBSD
Each Lisp mp:process has a separate native thread. You can have many
runnable mp:process objects/native threads, but Lisp code can only run
in one thread at a time and a lock is used to enforce this. This can
limit performance on multi-CPU machines."
regards,
Ralph
--
Raffael Cavallaro, Ph.D.
George Neuner
Yes. The issue, though, is how easy (or hard) any of them make
writing a Windows service application.
If ACL or LW have a ready framework for writing services then one of
them would obviously be a better choice. For embedding in a C or C#
framework, Corman is probably the easiest to work with.
George
Zach Beane
The Allegro one I remember from their NFS server for Windows:
http://opensource.franz.com/ntservice/
I've never tried it myself. Maybe they have something newer now.
Zach
jos...@corporate-world.lisp.de
Corman CL supports full multi-core-threading on Windows. It is not
free, but not very expensive.
A port of Clozure CL to Windows is in the works.
http://trac.clozure.com/openmcl/wiki/WindowsNotes
Clozure CL should also support multi-core-threads.
As already mentioned, LispWorks last year announced
that they are working on a multi-core-threaded
implementation. Currently there is no information
when it will be released.
jos...@corporate-world.lisp.de
<raffaelcavall...@pas.espam.s.il.vous.plait.mac.com> wrote:
I'm not sure that it does not use multiple cores. The current version
does not run multiple native Lisp threads **concurrently** on multiple
cores. It could still run **non-concurrently** on multiple cores.
Raffael Cavallaro
<jos...@corporate-world.lisp.de> said:
> The current version
> does not run multiple native Lisp threads **concurrently** on multiple
> cores. It could still run **non-concurrently** on multiple cores.
This is up to the OS scheduler. However, if the OS scheduler switches
the lisp between multiple cores the lisp is still limited by only being
able to use one core at a time.
That said, I have lispworks code that uses multiple cores
simultaneously - some threads that are pure foreign calls, and some
threads that are in lisp, so at any given moment, one core runs lisp
threads, and the other core(s) can (at the OS scheduler's discretion)
run some of the the foreign code threads simultaneously. For example,
LWM is now using 175% CPU on my dual core laptop. It would probably
happily use 200% but there are other processes running ;^)
The more foreign threads you run (in my case, cocoa calls) the less of
an issue this is.
Florian Weimer
> Yes, but Windows select() _only_ works with sockets. _nix select()
> also works with files.
On Unix, file I/O does never block (even thought it costs time,
sometimes even more than network I/O).
D Herring
??
Yes it does. Particularly for NFS, faulty disks, etc. That "costs
time" is blocking.
Kaz Kylheku
> Raffael Cavallaro wrote:
>> On 2009-02-02 19:55:49 -0500, Zach Beane <xa...@xach.com> said:
>>
>>> Not true. Corman Lisp, Allegro Common Lisp, and LispWorks Common Lisp
>>> all support threads on Windows.
>>
>> Right, but with LispWorks for example only one thread can be running in
>> the lisp at a time. Others that are pure foreign calls might run
>> concurrently but you can't have two *lisp* threads running concurrently
>> on a multi core machine. So even though LispWorks uses native threads,
>> those native threads won't use multiple cores if those threads are
>> running lisp code.
>
>
> LispWorks 6.0 will not only have removed that limitation, but will
> actually introduce support for running threads on different cores.
To do that they will have to rethink their entire idiotic threading API.
Anyone who thinks that a PROCESS-WAIT function is a good idea, needs to go back
to at least the middle 1970's and read a few papers on concurrency.
How can you safely wait for a condition to become true, and be sure that it's
still true after you are done waiting, if you are not holding a lock, that is
atomically given up when you suspend, and re-acquired, and if you have not
re-tested that the condition is still true?
What they need to do is design a sane new multithreading API, and support the
old API as a backwards-compatibility layer on the new threading.
Threads participating using the old API can be routed to the acquisition of a
global mutex which will serialize them. The process-wait function can work
against that mutex: give up the mutex atomically to go to sleep, then
re-acquire the mutex and re-test the condition, possibly going back to sleep if
it's not true.
New-style thread can explicitly grab the mutex before entering any subsystem
based on the old-style threading. Or use some macro like
(mp:with-braindamaged-threading
(legacy-function))
The macro will acquire and release the necessary lock, with unwind protection.
Kaz Kylheku
Of course a lock has to be used, for process-wait to be correct!
There is no correct ``condition wait'' without ``monitor enter''.
See for instance:
_Monitors: an operating system structuring concept_, C. A. R. Hoare, 1974.
Doh! Was this crud by chance implemented before 1974?
jos...@corporate-world.lisp.de
> On 2009-02-03, Pascal Costanza <p...@p-cos.net> wrote:
>
>
>
> > Raffael Cavallaro wrote:
>
> >>> Not true. Corman Lisp, Allegro Common Lisp, and LispWorks Common Lisp
> >>> all support threads on Windows.
>
> >> Right, but with LispWorks for example only one thread can be running in
> >> the lisp at a time. Others that are pure foreign calls might run
> >> concurrently but you can't have two *lisp* threads running concurrently
> >> on a multi core machine. So even though LispWorks uses native threads,
> >> those native threads won't use multiple cores if those threads are
> >> running lisp code.
>
> > LispWorks 6.0 will not only have removed that limitation, but will
> > actually introduce support for running threads on different cores.
>
> To do that they will have to rethink their entire idiotic threading API.
>
> Anyone who thinks that a PROCESS-WAIT function is a good idea, needs to go back
> to at least the middle 1970's and read a few papers on concurrency.
There are a lot of things that need to be changed. If you have a
specific
application in that area that you want to run on LispWorks
(with concurrent multi-core threading) contact them and let them know
your
requirements.
Madhu
* Kaz Kylheku <200902092...@gmail.com> :
Wrote on Tue, 3 Feb 2009 23:49:07 +0000 (UTC):
|
| To do that they will have to rethink their entire idiotic threading API.
|
| Anyone who thinks that a PROCESS-WAIT function is a good idea, needs
| to go back to at least the middle 1970's and read a few papers on
| concurrency.
There is nothing wrong with PROCESS-WAIT as an API function in the old
CLIM-SYS multi threading model unless you are trying to use it with the
PTHREADS API which is really a different model with different
characterestics.
| How can you safely wait for a condition to become true, and be sure
| that it's still true after you are done waiting,
Because the other multiprocessing code would conform to your model.
| if you are not holding a lock, that is atomically given up when you
| suspend, and re-acquired, and if you have not re-tested that the
| condition is still true?
This gives away your presumptions on the model. I assume you are using
the PTHREADS API for locks.
| What they need to do is design a sane new multithreading API, and support the
| old API as a backwards-compatibility layer on the new threading.
I believe, but do not know for sure, that SCL, Openmcl all provide this
already, i'm guessing they had this idea before
--
Madhu
David Lichteblau
> Yes. The issue, though, is how easy (or hard) any of them make
> writing a Windows service application.
It is very easy implement a Windows service in Lisp.
> If ACL or LW have a ready framework for writing services then one of
> them would obviously be a better choice. For embedding in a C or C#
> framework, Corman is probably the easiest to work with.
ntservice.cl by Franz works well and is unproblematic to use.
Note that it is free software under Lisp-LGPL. It uses Allegro's FFI,
but should be easy to translate to CFFI, and would also work on other
Lisps then.
(In fact, it would be very easy to rewrite it from scratch based on
Microsoft documentation if you had to, but the existing ntservice.cl
code makes things even easier.)
d.
George Neuner
wrote:
File I/O can block on local disks due to share locking. It can block
on network file shares for any number of reasons.
George
Kaz Kylheku
Your point is correct. However, the kind of blocking that happens in files
cannot be multiplexed with select and poll. Classic Unix has no support for
doing that; in the modern specification, there is <aio.h>.
http://www.opengroup.org/onlinepubs/009695399/basedefs/aio.h.html
If we peek into Linux, for instance, we can see that neither the block file
operations nor the ext2 file operations include a poll virtual function, the
lack of which means that the corresponding objects will unconditionally poll
positive for reading and writing. That is not only not useful, but it
interferes with polling other descriptors by causing poll or select to return
right away.
Polling is really for devices which may cause indefinite suspension that
may occur regardless of the transmission speed or latency.
George Neuner
<kkyl...@gmail.com> wrote:
>On 2009-02-06, George Neuner <gneu...@comcast.net> wrote:
>> On Tue, 03 Feb 2009 23:20:47 +0100, Florian Weimer <f...@deneb.enyo.de>
>> wrote:
>>
>>>* George Neuner:
>>>
>>>> Yes, but Windows select() _only_ works with sockets. _nix select()
>>>> also works with files.
>>>
>>>On Unix, file I/O does never block (even thought it costs time,
>>>sometimes even more than network I/O).
>>
>> File I/O can block on local disks due to share locking. It can block
>> on network file shares for any number of reasons.
>
>Your point is correct. However, the kind of blocking that happens in files
>cannot be multiplexed with select and poll. Classic Unix has no support for
>doing that; in the modern specification, there is <aio.h>.
>http://www.opengroup.org/onlinepubs/009695399/basedefs/aio.h.html
>
Yes.
>If we peek into Linux, for instance, we can see that neither the block file
>operations nor the ext2 file operations include a poll virtual function, the
>lack of which means that the corresponding objects will unconditionally poll
>positive for reading and writing. That is not only not useful, but it
>interferes with polling other descriptors by causing poll or select to return
>right away.
>
>Polling is really for devices which may cause indefinite suspension that
>may occur regardless of the transmission speed or latency.
The point I was trying to make was only that Unix select() and poll()
can detect a signaled file handle while Windows select() cannot.
George