<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Dear Eli, Thanks for your elaborate reply. I must admit that you are right on a lot of points. There's one advantage of having the "non blocking" ffi call, and that is: one keeps access to the returned C results, without having to serialize the results over a pipe. That said. The current mzscheme source distribution depends already on threads afaik (have a look in the gc subdir?). Best wishes, --Hans Eli Barzilay schreef: <blockquote cite="mid:18077.5586.73720.311043@kinyarwanda.ccs.neu.edu" type="cite"> <pre wrap="">On Jul 17, Hans Oesterholt-Dijkema wrote: </pre> <blockquote type="cite"> <pre wrap="">I'm sorry. It may be a matter of taste, but I don't like this solution. Also, starting a starting and synchronizing a thread is usually way faster than starting a subprocess. Kernels typically have special logic to support threads these days. </pre> </blockquote> <pre wrap=""> First of all, I have to say that I'm *very* aware of costs... It will be hard to find me write code that spends CPU cycles where they can be avoided. But of course there are factors that can be worth the CPU cycles -- if it makes it easier to develop, extend, and maintain. (And there are plenty of these in PLT.) In this specific case, when I consider all the factors (those that I'm aware of, obviously), I see an overwhelming advantage for the solution I suggested: * First of all: it's all Scheme code. This is a major benefit in almost every aspect. * It's portable across all platforms. No need to deal with various Linux thread packages, which is probably worse when dealing with cases like BSD or Solaris. * It's easy to deal with state. For example, you need to authenticate to the DB, run a query, then disconnect -- you can do all that in a single such sub-process. No complications. * Another example: take Noel's suggestion of letting the user control thread allocation and thread use -- with the Scheme code it's all very easy to achieve. It's also easy to keep a subprocess on hold after it's done, and re-use it next time you need an async operation. My guess is that doing all that in C will be much more painful. BTW, I looked at your code -- and it looks like you're starting a new thread for each async call, so if you have several of these, then it's likely to be more expensive than starting a single subprocess. * It's a pretty simple interface, compared to everything that you can do with threads. (Related disadvantage: you cannot do everything that you can do with threads.) * The only major disadvantage that I can think of is the cost of starting a process (which in this case includes the cost of booting mzscheme). But: - if you keep such subprocess alive, then you don't pay that cost for every async use - you say that the operation is heavy enough that you don't want the GUI to be frozen while it is done -- and I think if this is the case then you have much higher costs for the DB operation itself, so the subprocess would not be a significant (or even noticeable) contribution. * (BTW: On sane OSs, forking a process is almost as cheap as running a thread -- and that's pretty close to the external process approach.) I do think that there is a value in making async calls that use threads. But I'm not convince that this is the case with the problem you describe. </pre> <blockquote type="cite"> <pre wrap="">Did you have a look at the spike I sent to the list? It missed the code in c-threads.c, but that can be found in the sqld-psql-c.plt package. </pre> </blockquote> <pre wrap=""> I skimmed through it. IIUC, it is better done as a flag for the actual call-out, and the interface from Scheme is basically the same except that Scheme threads will continue to run as usual. So instead of a callback or a sync event you just do the foreign code in a Scheme thread. This sounds (again, IIUC) like a good approach. The first thing to do is to be very sure that your `c-threads' code works fine (and behaves the same) on all platforms. </pre> </blockquote> </body> </html>