RE: concurrent timers on linux
Hi Gilad, first, thanks for your efforts to help. I'll try to give a brief explanation of what I'm trying to do. Well, I'll not use the word timer, but timeout. In any case, I'll be glad to hear from you if, still, timers were not the correct wording here. I'm working as a freelancer for a company involved in cellular communications and I was asked to write a kind of connections manager application. My application has to be able to manage concurrent (parallel) connections to some multicell systems, which may be roughly defined as celllular centrals. Those multicell systems exchange messages with my application for some tasks to be done by my application. In addition, there is a kind of software (let's call it client software) that knows to communicate with those multicell systems through my application. So, basically there may be such client software used on various other computers at the same time and should be connected to my application concurrently. And yet also, my application has to connect to an ftp server to upload some kind of files. As I said, all connections have to be concurrent and not blocking others. I chose for this the multithread approach, where each connection is a thread. Yeah, I know, many people would advise using non-blocking sockets here, but this is my weak part and I was in ahurry, so I decided to postpone this learning curve to a later occasion and chose multithreads. Why timeouts? For example, a timeout to block the ftp thread, which after it there is a reconnection to ftp server for upload. In case there is no connection to any of the multicell systems, a timeout to wait and then retry connection again. In case of connection with what I called client software, I have a very simple ling-pong protocol to make sure there is connection between this software and my application and again after my application sends a ping it should wait for an adjustable time (by default 10 seconds) for the pong reply. So, as you see, various timeouts and all of them should be able to proceed cuncurrently and unaffected by any other one. Unfortunately, what I see in my case is that the most recent timeout takes the lead on all other blocked threads at that time and affects their timeouts. So for example, if the recent timeout was the one for the ftp and it is for a couple of hours, all the other threads that were blocked for their timeouts, remain blocked all along the last one. And here lies my problem. If you say that the system has a single timer than that may well be the problem, and each thread needs to have it's own independent timer (timer again?). So, I do think there is a problem with my strategy. If you say thet pthread_cond_timedwait blocks the whole system, this is bad. I intended to block a single thread, and that's what I thought it should do. Concerning clock_gettime function, there is an alternative of CLOCK_THREAD_CPUTIME_ID as it's first argument. I did not try it yet, but may be this could lead to a better solution. Ah, very lengthy message, still clear I hope. I'll be glad to continue and receive assistance. Thanks Gilad, Rafi. -Original Message- From: Gilad Ben-Yossef [mailto:[EMAIL PROTECTED] Sent: Saturday, November 10, 2007 10:23 AM To: Rafi Cohen Cc: linux-il@cs.huji.ac.il Subject: Re: concurrent timers on linux Rafi Cohen wrote: My application is a multithread one, for which each thread has it's own timer and tasks upon timeout. Each timer may be different (varies from 10 seconds in one case to 24 hours in another). Each timer should also be independent and the threads should run concurrently withou actually affecting other threads and timers. POSIX only supply a single timer counting in real time for each process. Multiple timers are either created by the programmer based on this single timer using a timer heap or the same done by the threading library pthread create_timer. It seems that there still is some effect of some timers to others and I don't achieve the goal of total independency of timers. There is just one timer. Here is the strategy I decided to use, by the way, my code is in C: Each thread uses in a loop the function pthread_cond_timedwait. Part of them may exit either upon signal or time out and part of them actually waits until timeout. This is not a timer. It's a blocking system call with a timeout. The problem I think I see is the timer adjustment prior to using pthread_cond_timedwait. What timer? you're using a blocking system call with a timeout. I sould also note that each thread has it's own and unique mutex and condition variables for this function. The time adjustment is done by calling clock_gettime with CLOCK_REALTIME as it's first parameter. This is called before each use of pthread_cond_timedwait and immediately after call to clock_gettime I add the timeout seconds to the tv_sec field of the timespec structure. Now, to my questions: 1. Does this strategy seem correct, if not please give
RE: concurrent timers on linux
Thanks, Guy, I'll try this debugging. Howeer, befor that I want to make sure I'm using the correct mechanism for timeout. For example, within the thread that needs to wait 10 seconds, the sample code is as follows: struct timespec tmspec; int retcode; Clock_gettime(CLOCK_REALTIME, tmspec); Tmspec.tv_sec += (seconds to wait until timeout). Then within the loop: lock mutex, retcode = pthread_cond_timedwait(cond, mutex, tmspec); Unlock mutex and then check if retcode == ETIMEDOUT, process on. Does this seem to be corrct, specifically the seconds I add to tmspec.tv_sec? Thanks, Rafi. -Original Message- From: guy keren [mailto:[EMAIL PROTECTED] Sent: Sunday, November 11, 2007 12:23 AM To: Rafi Cohen Cc: 'Gilad Ben-Yossef'; linux-il@cs.huji.ac.il Subject: Re: concurrent timers on linux i think you have a simple bug in your code that causes the behaviour you're talking about. i would suggest that, as an exercise, you write a program with only 2 threads, have one of them wait (with pthread_cond_timedwait) for 10 seconds and then print a message with the thread ID and current time, and the second thread wait for 15 seconds and print a similar message. run this code in a loop, and see if you can get the threads to work as expected (i.e. one prints a message every 10 seconds, the other prints it every 15 seconds). i guess that if you get this working properly, you'll be able to see why your program is not working as expected. --guy Rafi Cohen wrote: Hi Gilad, first, thanks for your efforts to help. I'll try to give a brief explanation of what I'm trying to do. Well, I'll not use the word timer, but timeout. In any case, I'll be glad to hear from you if, still, timers were not the correct wording here. I'm working as a freelancer for a company involved in cellular communications and I was asked to write a kind of connections manager application. My application has to be able to manage concurrent (parallel) connections to some multicell systems, which may be roughly defined as celllular centrals. Those multicell systems exchange messages with my application for some tasks to be done by my application. In addition, there is a kind of software (let's call it client software) that knows to communicate with those multicell systems through my application. So, basically there may be such client software used on various other computers at the same time and should be connected to my application concurrently. And yet also, my application has to connect to an ftp server to upload some kind of files. As I said, all connections have to be concurrent and not blocking others. I chose for this the multithread approach, where each connection is a thread. Yeah, I know, many people would advise using non-blocking sockets here, but this is my weak part and I was in ahurry, so I decided to postpone this learning curve to a later occasion and chose multithreads. Why timeouts? For example, a timeout to block the ftp thread, which after it there is a reconnection to ftp server for upload. In case there is no connection to any of the multicell systems, a timeout to wait and then retry connection again. In case of connection with what I called client software, I have a very simple ling-pong protocol to make sure there is connection between this software and my application and again after my application sends a ping it should wait for an adjustable time (by default 10 seconds) for the pong reply. So, as you see, various timeouts and all of them should be able to proceed cuncurrently and unaffected by any other one. Unfortunately, what I see in my case is that the most recent timeout takes the lead on all other blocked threads at that time and affects their timeouts. So for example, if the recent timeout was the one for the ftp and it is for a couple of hours, all the other threads that were blocked for their timeouts, remain blocked all along the last one. And here lies my problem. If you say that the system has a single timer than that may well be the problem, and each thread needs to have it's own independent timer (timer again?). So, I do think there is a problem with my strategy. If you say thet pthread_cond_timedwait blocks the whole system, this is bad. I intended to block a single thread, and that's what I thought it should do. Concerning clock_gettime function, there is an alternative of CLOCK_THREAD_CPUTIME_ID as it's first argument. I did not try it yet, but may be this could lead to a better solution. Ah, very lengthy message, still clear I hope. I'll be glad to continue and receive assistance. Thanks Gilad, Rafi. -Original Message- From: Gilad Ben-Yossef [mailto:[EMAIL PROTECTED] Sent: Saturday, November 10, 2007 10:23 AM To: Rafi Cohen Cc: linux-il@cs.huji.ac.il Subject: Re: concurrent timers on linux Rafi Cohen wrote: My application is a multithread one, for which each thread has it's own timer and tasks upon timeout. Each
concurrent timers on linux
Hi list, I raised this question a long time ago when I had to write my application and got a couple of suggestions. I chose my strategy, but it seems I still have major problems. Terefore, I return to you to ask for more advise. My application is a multithread one, for which each thread has it's own timer and tasks upon timeout. Each timer may be different (varies from 10 seconds in one case to 24 hours in another). Each timer should also be independent and the threads should run concurrently withou actually affecting other threads and timers. It seems that there still is some effect of some timers to others and I don't achieve the goal of total independency of timers. Here is the strategy I decided to use, by the way, my code is in C: Each thread uses in a loop the function pthread_cond_timedwait. Part of them may exit either upon signal or time out and part of them actually waits until timeout. The problem I think I see is the timer adjustment prior to using pthread_cond_timedwait. I sould also note that each thread has it's own and unique mutex and condition variables for this function. The time adjustment is done by calling clock_gettime with CLOCK_REALTIME as it's first parameter. This is called before each use of pthread_cond_timedwait and immediately after call to clock_gettime I add the timeout seconds to the tv_sec field of the timespec structure. Now, to my questions: 1. Does this strategy seem correct, if not please give other ideas. 2. Specifically, is the function clock_gettime the correct one to use, should it's first parameter be the one I use and should it be called indeed before each pthread_cond_timedwait within the loop, or only once before the loop. I'll be glad to have detailed ideas, in case you think I'm wrong here. 3. Shachar (Shemes), you pointed me once to the libevent library as an alternative. I looked into this library and was very willing to use it. However, I understood from it's documentation that it is not threadsafe. Therefore, it seems not to be the right idea to use it for concurrent timers. Am I wrong here? I'll be glad to stand corrected and use such option instead of the strategy I mentioned above. Any assistance will be most appreciated. Note: I raise programming issues here from time to time and get good answers most of the time. However, probably there are more linux users than programmers here. So, if you think there should be a better forum or mailing list to raise such questions, then please let me know. I do think however, that there are here really knowledgeable people that may and I believe will help the best they can. Thanks, Rafi.
integrating ftp client within an application on linux
Hi, I'm writing an application in C on linux that one of it's components is the ability to upload and download files to/from an ftp server. I would like to know if there is an open source ftp api that I can integrate in my application? Well, I foud one -- libncftp, but after evaluation of 30 days, this api has to be paid for further use, so I'm looking for other options. If there is no such api, does this mean that I need to run the ftp client on the system using stuff like exec, fork etc? Any help will be most appreciated. Thanks, Rafi.
RE: integrating ftp client within an application on linux
Thanks. It seems I should make a better search. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Amos Shapira Sent: Friday, October 26, 2007 1:08 AM To: linux-il@cs.huji.ac.il Subject: Re: integrating ftp client within an application on linux On 26/10/2007, Rafi Cohen [EMAIL PROTECTED] wrote: Hi, I'm writing an application in C on linux that one of it's components is the ability to upload and download files to/from an ftp server. I would like to know if there is an open source ftp api that I can integrate in my application? Well, I foud one -- libncftp, but after evaluation of 30 days, this api has to be paid for further use, so I'm looking for other options. If there is no such api, does this mean that I need to run the ftp client on the system using stuff like exec, fork etc? Any help will be most appreciated. Thanks, Rafi. A quick search on SourceForge came up with http://sourceforge.net/projects/libftp/, for example. --Amos
RE: multithread problem
Hi Guy, thanks for your reply. I should have debugged this better,
indeed I found the racy condition.
I should happen in a most rare and extreme case, but since it did, it
required it's treatment and solution.
Now problem is solved and everything works appropriately.
Thanks, Rafi.
-Original Message-
From: guy keren [mailto:[EMAIL PROTECTED]
Sent: Monday, May 21, 2007 1:49 PM
To: Rafi Cohen
Cc: [EMAIL PROTECTED] Org. Il
Subject: Re: multithread problem
Rafi Cohen wrote:
Hi, I'm asking for further assistance for yet another problem I
encounter with my project, this time concerning multithreads.
In order to explain my problem, I'll write a short example:
main:
pthread_mutex_lock(mut);
flag = 0;
pthread_cond_broadcast(cond);
printf(after signal: flag=%d\n, flag);
pthread_mutex_unlock(mut);
thread:
pthread_mutex_lock(mut);
while (flag)
{
pthread_cond_wait(cond, mut);
printf(after wait: flag=%d\n, flag);
}
pthread_mutex_unlock(mut);
this code looks ok.
Now, after signal I indeed see that flag is 0.
Flag is assigned 1 in 2 other places in main, in both cases surrounded
by lock and unlock of the same mutex.
this sounds bad.
Wha happens, that after wait, flag is still 1 and the thread is stuck
in
the loop, and I feel helpless.
when the main thread has set flag to 0, sent a broadcast and unlocked
the mutex, you are not guranteed which of the threads waiting on this
mutex will wake up first and acquire the mutex.
it could be that main's code continues running, locks the mutex again
and set flag to 1.
all this shows you've got a bad design. for instance - why does 'main'
set the flag to 1? this is racy. what is te purpose of this flag? what
are you trying to accomplish?
--guy
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/813 - Release Date: 5/20/2007
7:54 AM
=
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word unsubscribe in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
multithread problem
Hi, I'm asking for further assistance for yet another problem I
encounter with my project, this time concerning multithreads.
In order to explain my problem, I'll write a short example:
main:
pthread_mutex_lock(mut);
flag = 0;
pthread_cond_broadcast(cond);
printf(after signal: flag=%d\n, flag);
pthread_mutex_unlock(mut);
...
thread:
pthread_mutex_lock(mut);
while (flag)
{
pthread_cond_wait(cond, mut);
printf(after wait: flag=%d\n, flag);
}
pthread_mutex_unlock(mut);
..
Now, after signal I indeed see that flag is 0.
Flag is assigned 1 in 2 other places in main, in both cases surrounded
by lock and unlock of the same mutex.
Wha happens, that after wait, flag is still 1 and the thread is stuck in
the loop, and I feel helpless.
This code is based on my understandings from the documentation about
threads and also follows the examples I saw.
What should I do so that after wait flag will be 0 as I expect it to be
according to this example?
If this is not directly in this code piece, maybe somebody can give me
some clues what may cause flag to remain 1 after wait to see if anything
of this exists in the whole program.
Thanks, Rafi.
RE: need some help with tcp/ip programming
Hi Guy, well, to continue your terminology I feel not only foolish but a total moron, since I was not aware at all of this book. I'll be glad to receive a reference to this book in order to become cleverer. After all, this is a desire of any pprogrammer, if he does not already feel so beforehand. But seriously now, I based my learning excet on man pages, also on something I found on the internet called Beej S guide for network programming using internet sockets. Not a deeply detailed one, but still not bad with lots of valuable example. Just what I needed as a programmer working under managers that want their project to finish yesterday whereas the programmer himself needs to learn the subject just today. Again, I'll be glad to learn more on this subject regardless of the current project. However, as a blind erson, reading printed books requires many effort and time for me, and I sure preffer electronic format books (pdf etc). So if you can point me to an electronic format of Stevens' book, I'll much appreciate it. 2 more coments to what you said below: 1. As Amos already mentioned this in a separate message, I also got the impression from the documents that using select makes irrelevant to set the sockets as nonblocking, so did not bother with this at all. But if you say that there still are cases that read after select does block, you probably base on your experience and no doubt you are much more experienced than me in this area, so I'll take this under consideration. 2. I indeed was one of the people that was not aware of epoll until you mentioned it. I began to read the man pages related to epoll, but for the time being terminology like edge triggered or level triggered need deeper understanding from my side. I'll search the net for better documentation, but if anybody can give me brief explanation of this and which of them is relevant for my case, I'll be more than glad to listen and learn. Thanks, Rafi. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of guy keren Sent: Tuesday, May 15, 2007 3:17 AM To: Amos Shapira Cc: Linux-IL Subject: Re: need some help with tcp/ip programming Amos Shapira wrote: On 15/05/07, *guy keren* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think you are tinkering with semantics and so miss the real issue (do you work as a consultant? :). did you write that to rafi or to me? i'm not dealing with semantics - i am dealing with a real problem, that stable applications have to deal with - when the network breaks, and you never get the close from the other side. I wrote this to you, Guy. Rafi maybe used disconnect when he basically ment that the TCP connection went down from the other side while you seemed to hang on disconnect being defined as cable eaten by an aligator :). lets leave this subject. i brought it up, because many programmers new to socket programming are surprised by the fact that a network disconnection does not cause the socket to close, and that the connection may stay there for hours. As long as Rafi feels happy about the replies that's not relevant any more, IMHO. Alas - I think that I've just read not long ago that there is a bug in Linux' select in implementing just that and it might miss the close from the other side sometimes what you are describing here sounds astonishing - that such a basic feature of the sockets implementation is broken? i find this hard to believe, without clear evidence. Here is something about what I read before, it's the other way around, and possibly only relevant to UDP but I'm not sure - if a packet arrives with bad CRC, it's possible that the FD will be marked as ready to read by select but then the packet will be discarded (because of the CRC error) and when the process reads the socket it won't get anything. That would make the process get a 0 read right after select which does NOT indicate a close from the other side. http://www.uwsg.indiana.edu/hypermail/linux/kernel/0410.2/0001.html I don't know what would be a select(2)-based work-around, if required at all. first, it does not return a '0 read'. this situation could have two different effects, depending on the blocking-mode of the socket. if the socket is in blocking mode (the default mode) - select() might state there's data to be read, but recvmsg (or read) will block. if the socket is in non-blocking mode - select() might state there's data to be read, but recvmsg (of read) will return with -1, and errno set to EAGAIN. in neither case will read return 0. the only time that read is allowed to return 0, is when it encounters an EOF. for a socket, this happens ONLY if the other side closed the sending-side of the connection. ofcourse, whenever i did select-based socket programming, i always set the sockets to non-blocking mode. this requires some careful programming, to
RE: need some help with tcp/ip programming
Hi Shachar, can you please give more detailed explanation why a thread per socket is not a wise idea? Not that I'm in a hurry to impplement this way, but I'll give you an example where I thought this could be a solution for me. One of the requirements of my project asks that my application, when it is a client, will actually make endless attempts to connect some of the servers, until any of the servers comes alive and the connection is established. (an interesting subject of it's own, which to one problematic ussie of this, I'll relate further below.) You probably agree that this caanot be done form the main thread. I ended by implementing a thread just for this. Attempting to connect endlessly until the connection is established and exits while raising a flag which the main thread checks just before each select to add the appropriate file descriptor to the select/poll array of descriptors. However, I do ask myself what's wrong in creating a thread per socket? In this thread I could try to connect, which in case it does not connect whould not disturb any other thread and when connected, would continue to oerate concurrently with the other threads. So, yyes, please explain what could be unwise in such an implementation. Concerning the endlss loo of connect(), a person on the remote computer told me that when a server is not alive there, those endless connects stuck the computer and his only way to free it is by unplugging the ethernet wire. Upon replugging it, everything works again. So, I'm ask to sleep for some seconds between each attempt to connect. Can you the experienced people coment on this? Is this event a known one and would indeed the delay of some seconds solve this? Or the reason to this event is something else? Thanks, Rafi. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shachar Shemesh Sent: Tuesday, May 15, 2007 8:14 AM To: Amos Shapira Cc: Linux-IL Subject: Re: need some help with tcp/ip programming Amos Shapira wrote: in neither case will read return 0. the only time that read is allowed to return 0, is when it encounters an EOF. for a socket, this happens ONLY if the other side closed the sending-side of the connection. Is there an on-line reference (or a manual page) to support this? man 2 read From what I remember about select, the definition of it returning a ready to read bit set is the next read won't block, which will be true for non-blocking sockets any time and therefore they weren't encouraged together with select. I believe you two are talking about two different things here. There is a world of difference between UDP and TCP in that regard. UDP is connectionless. This means that read's error codes relate only to the latest packet received. UDP also doesn't have a 100% clear concept of what CRC/checksum actually means. I still think it's a bug for select to report activity on a socket that merely received a packet with bad checksum (there is no CRC in TCP/IP), as how do you even know it was intended for this socket? In TCP, on the other hand, a read is related to the connection. Packets in TCP are coincidental. Under TCP, read returning 0 mean just one thing - the connection is close. if you have so many connections that multiple threads will become a problem then a single thread having to cycle through all these connections one by one will also slow things down. No, my experience begs to differ here. When I tested netchat (http://sourceforge.net/projects/nch), I found out that a single thread had no problem saturating the machine's capacity for network in/out communication. As long that your per-socket handling does not require too much processing to slow you down, merely cycling through the sockets will not be the problem if you are careful enough. With netchat, I used libevent for that (see further on for details), so I was using epoll. Your mileage may vary with the other technologies. Not to mention the signal problem and just generally the fact that one connection taking too much time to handle will slow the handling of other connections. Yes, it is probably better to use a single thread that does the event waiting, and a thread pool for the actual processing. Having one thread pet socket, however, is not a wise idea IMHO. A possible go-between might be to select/poll on multiple FD's then handing the work to threads from a thread pool, but such a job would be justifiable only for a large number of connections, IMHO. It's not that difficult to pull off, and I believe your analysis failed to account for the overhead of creating new threads for each new connection, as well as destroying the threads for no longer needed connections. If you insist on using a single thread then select seems to be the underdog today - poll is just as portable (AFAIKT), and Boost ASIO (and I'd expect ACE) allows making portable code which uses the superior API's such as epoll/kqueue/dev/poll.
RE: need some help with tcp/ip programming
Hi Nadav, well, in my case I do not have thousands of concurrent connections, about 20-30 only. However, in some cases the input from those sockets is actually queries to a database and it may also end in operations on this database. Not a heavy database, but still insert/delete/update is done occassionally. Now, if I understand you correctly, you say that using a single thread with epoll, even with many concurrent connections will not decrease performance. Does this remain correct for my case, as explained above? For the time being, I do use a single thread with select mechanism which I'll modify to epoll once I understand it's usage. However, I do feel that multithread after epolll returns with an event may significantly increase concurrency and performance. I'll be glad to have your opinion about this. Thanks, Rafi. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nadav Har'El Sent: Tuesday, May 15, 2007 3:23 PM To: guy keren Cc: [EMAIL PROTECTED]; Amos Shapira; Linux-IL Subject: Re: need some help with tcp/ip programming On Mon, May 14, 2007, guy keren wrote about Re: need some help with tcp/ip programming: this is interesting. can anyone provide more info on this? the problem with select, is that it is unable to optimize handling of 'holes' in the file descriptor set. suppose that you need to select on file descriptors 2 and 4000. you need to pass info about all file descriptors up to 4000 (i.e. many '0' bits, and only two '1' bits, in the different select sets). with poll, you pass an array of the descriptors you care about. so the size of the array is proportional to the amount of descriptors you are interested in, while with select it is proportional to the numeric value of the largest descriptor you are interested in. This is indeed an accurate accessment of the difference between pol and select. Another point worth noticing is that in select(), the same array is used both as input and output. This means that after every event, you need to refill this array, which can be quite slow if you have many thousands of events per second. In some cases, you reach a point where you are listening to thousands of file descriptors, and getting thousands of events per second. For example, one can write a single-threaded HTTP server which handles thousands of concurrent connections with amazing performance (I wrote such a server once, and it was a really interesting experience). When you reach such high demands, even poll() is not good enough - every time one fd is ready to act on, something which can happen thousands of times per second - you need to call the poll() system call again, and pass to the long array of fds from userspace to the kernel. The problem is that the time poll() takes is proportional to the number of fds to poll, rather than to the number of fds in which something actually happened. To solve this problem, the /dev/epoll interface was added to Linux in 2001, and later, apparently because Linus Torvalds doesn't like /dev tricks, new system calls were added instead (see epoll(4))). It was amazing to see a system on which Apache stuggled to keep 200 concurrent open connections, suddenly keep thousands of concurrent open connections, using only one thread (or N threads in a machine with N cpus). Together with sendfile(), this allows you to create killer Web servers :-) when you use poll, you can use the trick of having 2 theads - one polls on idle sockets (i.e. sockets that did not have I/O in the last X seconds), and one listens on 'active' sockets (i.e. sockets that had I/O in the last X seconds). this avoids the major problem with both select and poll - that after an event on a single socket, the info for all the sockets has to be copied to user space (when select/poll returns), and then to kernel space again (when invoking poll/select again). i think that people added epoll support in order to avoid waking the poll function altogether - by receiving a signal form the kernel with the exact info, instead of having to return from poll. Indeed (see my above explanation). epoll() *does* return from the poll every time, but it immediately lets you know what changed (no need to check a long array), and more importantly - when you want to call epoll() again there is no need to pass the long list of fds to the kernel again. -- Nadav Har'El| Tuesday, May 15 2007, 27 Iyyar 5767 [EMAIL PROTECTED] |- Phone +972-523-790466, ICQ 13349191 |Ms Piggy's last words: I'm pink, http://nadav.harel.org.il |therefore I'm ham. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.467 / Virus
need some help with tcp/ip programming
Hi, as a pproject for a company I'm writing a tcp/ip application on linux using C language. My application has 2 connections as client to remote servers and is by itself a server accepting remote client connections. I'm using select() mechanism to manage all those connections. Everyting works nicely until any of the remote sideds disconnects. In some of such cases, I'm not succeeding to reconnect to this remote as client or re-accept connection from tjhe remote client. Reading some documentation on tcp/ip programming, I had the impression that the select mechanism should detect such remote disconnect event, thus enabling me to make a further read from this socket which should end in reading 0 bytes. Reading 0 bytes should indicate disconnection and let me disconnect propperly from my side and try to reconnect. However, it seems that select does not detect all those disconnect events and even worse, I can not see any rule behind when it does detect this and when it does not. So, I have a couple of questions and I'll most apreciate any assistance. 1. Would you confirm that select, indeed, does not detect each and every remote disconnection and do you know if there is a rule behind those cases? 2. If I need to detect those disconnections to react propperly in my application and I can not rely on select, what would you suggest me to do? should I use a kind of ping mechanism to check every some seconds if the connection is still alive? or may be use multithread instead of select, where each thread is responsible for each connection source and instead of select I loop on read from this source and so, can detect when I read 0 bytes, which is the disconnect indication and react accordingly? Does this make sense or you see issues in such implementation also? Thanks, Rafi.
RE: need some help with tcp/ip programming
Hi Guy Rafi Cohen wrote: Hi, as a pproject for a company I'm writing a tcp/ip application on linux using C language. ah welcome, welcome to the pleasure dome... Hmm, thanks for your warm greetings. My application has 2 connections as client to remote servers and is by itself a server accepting remote client connections. I'm using select() mechanism to manage all those connections. Everyting works nicely until any of the remote sideds disconnects. In some of such cases, I'm not succeeding to reconnect to this remote as client or re-accept connection from tjhe remote client. you're not describing things properly here, since later you say you are not managing to disconnect (the problem is not with re-connecting - which, if happened, would imply a different problem altogether) You are correct, what I indeed meant to say is in order to re-connect, first I need to disconnect propperly and here lies my problem. Reading some documentation on tcp/ip programming, I had the impression that the select mechanism should detect such remote disconnect event, thus enabling me to make a further read from this socket which should end in reading 0 bytes. Reading 0 bytes should indicate disconnection and let me disconnect propperly from my side and try to reconnect. However, it seems that select does not detect all those disconnect events and even worse, I can not see any rule behind when it does detect this and when it does not. select does not notice disconnections. it only notices if the socket was closed by the remote side. that's a completely different issue, and that's also the only time when you get a 0 return value from the read() system call. Yes, this does make sense and I need to check with the software developer to which mine is connecting remotely, if he indeed closes the socket when disconnecting. You gave me a clue, thanks. So, I have a couple of questions and I'll most apreciate any assistance. 1. Would you confirm that select, indeed, does not detect each and every remote disconnection and do you know if there is a rule behind those cases? TCP/IP stacks on linux, by default, will only notice a network disconnection (i.e. the network went down) reliably after 2 hours. that's how TCP/IP's internal keep alive mechanism is set. 2 hours is a completely impractical value for any sane system you might develop. you can tweak this parameter of the TCP/IP stack for specific sockets, on current linux kernels, using a socket option. (man 7 tcp - and look for 'keepalive' - there are 3 parameters for this). i never used this mechanism, since it was only possible to make this change globally when i needed that. I know of this option and will look into that deeper. May be I miss here something, but this option may be relevant for the case my application is a server. I wonder how it would affect, if at all, when my application is a client. 2. If I need to detect those disconnections to react propperly in my application and I can not rely on select, what would you suggest me to do? should I use a kind of ping mechanism to check every some seconds if the connection is still alive? or may be use multithread instead of select, where each thread is responsible for each connection source and instead of select I loop on read from this source and so, can detect when I read 0 bytes, which is the disconnect indication and react accordingly? read would fail just like select does, and because of the same reason. you could implement the keepalive in your application, in case the keepalive parameters tweaking of the TCP stack does not work, for some reason. --guy Thanks, Rafi. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.0/803 - Release Date: 5/13/2007 12:17 PM = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
RE: need some help with tcp/ip programming
Amos, thanks for the ideas. I thought about poll and will look into this. I'm cecking read also for errors (valies 0) but in this case there ven can not be errors. Since the socket is disconnected, select does not detect any event on this socket and so does not give me any opportunity to read from it and even get an error. But thanks anyway. Rafi. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Amos Shapira Sent: Monday, May 14, 2007 1:16 PM To: Linux-IL Subject: Re: need some help with tcp/ip programming On 14/05/07, guy keren [EMAIL PROTECTED] wrote: Rafi Cohen wrote: Reading some documentation on tcp/ip programming, I had the impression that the select mechanism should detect such remote disconnect event, thus enabling me to make a further read from this socket which should end in reading 0 bytes. Reading 0 bytes should indicate disconnection and let me disconnect propperly from my side and try to reconnect. However, it seems that select does not detect all those disconnect events and even worse, I can not see any rule behind when it does detect this and when it does not. select does not notice disconnections. it only notices if the socket was closed by the remote side. that's a completely different issue, and that's also the only time when you get a 0 return value from the read() system call. I think you are tinkering with semantics and so miss the real issue (do you work as a consultant? :). Basically - Rafi expects (as he should) that a read(fd,...)==0 after a select(2) call that indicated activity on fd means that the other side has closed the connection. Alas - I think that I've just read not long ago that there is a bug in Linux' select in implementing just that and it might miss the close from the other side sometimes (sorry, can't find a reference with a quick google, closest I got to might be: http://forum.java.sun.com/thread.jspa?threadID=767657 http://forum.java.sun.com/thread.jspa?threadID=767657messageID=4386218 messageID=4386218). I don't remember what was the work-around to that. Another point to check - does the read(2) after select(2) return an error? See select_tut(2) for more details on how to program with select - you should check for errors as well instead of just assuming that read(2) must succeed ( e.g. interrupt). Also while you are at it - check whether pselect(2) can help you improve your program's robustness. Maybe using poll(2) will help you around that (I also heard that poll is generally more efficient because it helps the kernel avoid having to re-interpret the syscall parameters on every call). --Amos
RE: need some help with tcp/ip programming
Thank you very much Guy and sorry for not writing the text in an approriate way. Usually, I reply above the original message, but this time tried to mix my comments close to your text so that they make sense and you don't loose the context. Next time I'll try to do better. Thanks for the most valuable information, Rafi. -Original Message- From: guy keren [mailto:[EMAIL PROTECTED] Sent: Monday, May 14, 2007 11:18 PM To: Rafi Cohen Cc: '[EMAIL PROTECTED] Org. Il' Subject: Re: need some help with tcp/ip programming (rafi - your quoting mixes your text with mine - you might want to fix this - it was very hard to read your letter). see my comments below: Rafi Cohen wrote: Hi Guy Rafi Cohen wrote: So, I have a couple of questions and I'll most apreciate any assistance. 1. Would you confirm that select, indeed, does not detect each and every remote disconnection and do you know if there is a rule behind those cases? TCP/IP stacks on linux, by default, will only notice a network disconnection (i.e. the network went down) reliably after 2 hours. that's how TCP/IP's internal keep alive mechanism is set. 2 hours is a completely impractical value for any sane system you might develop. you can tweak this parameter of the TCP/IP stack for specific sockets, on current linux kernels, using a socket option. (man 7 tcp - and look for 'keepalive' - there are 3 parameters for this). i never used this mechanism, since it was only possible to make this change globally when i needed that. and rafi responds: I know of this option and will look into that deeper. May be I miss here something, but this option may be relevant for the case my application is a server. I wonder how it would affect, if at all, when my application is a client. it does not matter if you have a client or a server - you want to know about network problems either way - unless you assume that the client is a GUI and the user will simply hit the 'cancel' button. since in your case it does not appear to be a GUI - rather a longer-living server, then you might want to handle the disconnection issues both on your side, and on the side of the server. note that for some applications, it is enough to have a 'close the socket if it was idle for X time' - i.e. if you didn't get any data from a socket during X minutes - you close it. Thanks, Rafi. hope this makes it clearer. --guy -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.0/803 - Release Date: 5/13/2007 12:17 PM = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
RE: implement timers in a multi thread application
Gilad, thank you very much for your advise. I tend to implement it, but I still remain with the following question: if a thread has various timeout cases, for example, one after 10 seconds and another one after 40 seconds, how this could be implemented in the timers thread waiting for the SIGALRM signal upon sigwait() call? When alarm is called, for example with 10 as parameters, I know that SIGALRM will be received after (aproximately) 10 seconds. But, if I don't use the alarm call, then what? Is there a way to produce SIGALRM signal every constant number of seconds so that I can count the number of received SIGALRM signals and proceed according to the number that once sum up to 10 seconds and once sums up to 40 seconds? I hope I was clear here. Thanks, Rafi. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gilad Ben-Yossef Sent: Monday, January 08, 2007 8:52 PM To: Rafi Cohen Cc: [EMAIL PROTECTED] Org. Il Subject: Re: implement timers in a multi thread application Rafi Cohen wrote: Hi, I need some advice implementing timers in a multithread aplication on linux (suse 9.3, kernel 2.6.11). The application is written in C. At first, I chose to use alarm() with a handler for SIGALRM, but after some tests I concluded tht it's not wise to use this in a multithread application, since it seems that each call to alarm() affects or even cancels the previous one, even though the previous call was in another thread. Do I miss here something? may this still be used in a multithread application? Yes, I know about getitimer and setitimer, but I do not understand how to adjust the timer, for example if I want a timer of 20 seconds. If this is the solution you suggest, please provide an example that shows how to use those functions. Generally, any advise concerning this issue will be most appreciated. Thanks, Rafi. POSIX timers are per proccess not per thread. setitimer will still give you one timer per process (OK, actually it will give you 3 timers but each runs in a different time domain and you are only interested in wall clock timer it seems so you still have only one). To do what you want you need to write you on timers heap implmentation based on the single timer you have. You are advised to use a special timers thread for this that blocks with sigwait() for SIGALRM and mask out all other threads from receving SIGALRM if you want anything near sane application. Generally threads and signals mix badly and in POSIX a timer is implmented as a signal :-( Gilad = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.16.7/619 - Release Date: 1/7/2007 6:29 PM -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.16.7/619 - Release Date: 1/7/2007 6:29 PM To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
RE: implement timers in a multi thread application
Hi Amos, thank you very much for the clear and very informative reply. It seems I need some learning before this implementation and I'll do that right away based on your advises. Rafi. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Amos Shapira Sent: Tuesday, January 09, 2007 1:23 AM To: Linux-IL Subject: Re: implement timers in a multi thread application On 09/01/07, Rafi Cohen [EMAIL PROTECTED] wrote: Gilad, thank you very much for your advise. I tend to implement it, but I still remain with the following question: if a thread has various timeout cases, for example, one after 10 seconds and another one after 40 seconds, how this could be implemented in the timers thread waiting for the SIGALRM signal upon sigwait() call? You should sort of implement this as a little OS scheduler - pass a timer and a function to call to when the timer expires into a shared timer queue, regardless of which thread the scheduling is done from. Once the timer expires the main timer-handling thread should arrange that some worker thread will execute the function handed over to handle that timer expiry. When alarm is called, for example with 10 as parameters, I know that SIGALRM will be received after (aproximately) 10 seconds. But, if I don't use the alarm call, then what? Is there a way to produce SIGALRM signal every constant number of seconds so that I can count the number of received SIGALRM signals and proceed according to the number that once sum up to 10 seconds and once sums up to 40 seconds? No, what you should do is to implement a timer-queue - a shared linked list of timer events, each entry basically has a time left from now, function to call, void * ttiplet. That list should be ordered by increasing time left from now, each entry actually holding the difference in time between it and the one before it. The current alarm will be the first in the list and when the ALRM signal is received the timer scheduling thread can check that it's the right time to run the first entry in the list (passing it the void * given when the timer was added to the list) then clear it from the list and set the next alarm for the next timer on the list. The void * will be extremely important to provide context for the function which is being called when the timer expires. (Small implementation note - take into account possibility of multiple timers expiring at the same time, threads manipulating the list concurrently, and the list being changed while the timer thread is processing an alarm ( e.g. a function called from an expired timer adding a timer to call itself in a few more seconds). I've done this before (without threads, the POSIX standard wasn't commonly available back then) and it's quite fun to program, but today I'd recommend you to consider moving to C++ and maybe take advantage of libraries like Boost ( boost.org) or ACE (http://www.cs.wustl.edu/~schmidt/ACE.html, look for Concurrency in http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/docs/ACE-categories.html for a start) I hope I was clear here. Thanks, Rafi. HTH, --Amos -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.16.7/620 - Release Date: 1/8/2007 4:12 PM
RE: implement timers in a multi thread application
Shachar, thank you very much for the valuable link. At first glance, it indeed seems this is what I'm looking for and I'll investigate it deeper today. Thanks to all others who tried to help. I've learned a lot from this thread and it seems I have got the correct route to implement this. Thanks, Rafi. -Original Message- From: Shachar Shemesh [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 09, 2007 9:00 AM To: Rafi Cohen Cc: [EMAIL PROTECTED] Org. Il Subject: Re: implement timers in a multi thread application Rafi Cohen wrote: Hi, I need some advice implementing timers in a multithread aplication on linux (suse 9.3, kernel 2.6.11). The application is written in C. At first, I chose to use alarm() with a handler for SIGALRM, but after some tests I concluded tht it's not wise to use this in a multithread application, since it seems that each call to alarm() affects or even cancels the previous one, even though the previous call was in another thread. Do I miss here something? may this still be used in a multithread application? Yes, I know about getitimer and setitimer, but I do not understand how to adjust the timer, for example if I want a timer of 20 seconds. If this is the solution you suggest, please provide an example that shows how to use those functions. Generally, any advise concerning this issue will be most appreciated. Thanks, Rafi. I've read the entire thread, and it has some very correct advice from Gilad and others. However, before you start implementing away, I suggest you take a look at libevent (http://freshmeat.net/projects/libevent/). I believe it does all you're looking for (and quite a bit more), and may save you a considerable amount of time. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.16.7/620 - Release Date: 1/8/2007 4:12 PM -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.16.7/620 - Release Date: 1/8/2007 4:12 PM = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
implement timers in a multi thread application
Hi, I need some advice implementing timers in a multithread aplication on linux (suse 9.3, kernel 2.6.11). The application is written in C. At first, I chose to use alarm() with a handler for SIGALRM, but after some tests I concluded tht it's not wise to use this in a multithread application, since it seems that each call to alarm() affects or even cancels the previous one, even though the previous call was in another thread. Do I miss here something? may this still be used in a multithread application? Yes, I know about getitimer and setitimer, but I do not understand how to adjust the timer, for example if I want a timer of 20 seconds. If this is the solution you suggest, please provide an example that shows how to use those functions. Generally, any advise concerning this issue will be most appreciated. Thanks, Rafi. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.16.6/617 - Release Date: 1/5/2007 11:11 AM
RE: FW: primary address of devices
Ori, thank you very much for your fruitful coments. I accept them according to my experience and think I've found a solution. Just another question, if you don't mind. The devices attached to the board (gsm simulators) have their own keyboard which is disabled when in gpib mode, interacting with the computer. When the application exits, I close the gpib mode (ibonl(device, 0), but still, the control does not return to the device's keyboard and a user needs to make a manual reset to gain control again. Can you think what should I do more to achhieve this goal? is this a linux-gpib driver function that I have to call or do I have to write a command to gsm simulator that should do this prior to closing the gpib connection. I know you probably did not work with this specific device, but may be you encountered a similar problem with other devices with the same feature of keyboard. Thanks, Rafi. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ori Idan Sent: Sunday, December 24, 2006 9:22 AM To: Rafi Cohen Cc: [EMAIL PROTECTED] Org. Il Subject: Re: FW: primary address of devices 1. When issuing an ibfind (or ibdev) command, no hardware access is done so no error will be returned. however if you write or read to/from the device, the results are unpredictable. 2. IEEE4888.2 provides a way to enumerate the devices, I do not recall how it is done. However not all devices support it. 3. The name is not related to the device itself so you can call it any name you want. 4. Your other mail contained a question about select and gpib library, I think you can use select like you use on any other file or socket, however I have never tried it myself. In GPIB usually you do not need asynchronous transfer since devices never talk on their own will but allways as a result of the master issuing a query command. Disclaimer: All the above is written from my knowledge of GPIB (I have used GPIB for more then 10 years) not with knowledge about this specific library. -- Ori Idan On 12/24/06, Rafi Cohen [EMAIL PROTECTED] wrote: Hi list, I hope the following is not too offtopic and if it is, feel free to answer privately. Does anybody happen to know or work with linux-gpib driver? you may find details on http://linux-gpib.sourceforge.net. Ive sent the following 2 messages to the linux-gpib-general mailing list, but nobody answered me up to now. I hope somebody on this list may help me. I forward this message and another one, relating to 2 different subjects. Thanks, Rafi. -Original Message- From: Rafi Cohen [mailto:[EMAIL PROTECTED] Sent: Monday, December 18, 2006 1:08 PM To: [EMAIL PROTECTED] Sourceforge. Net Subject: primary address of devices Hi, sorry in advance if some of my questions are too basic and even not logic. My application needs to support connecting up to 30 devices (actually gsm simulators) to the gpib board in the computer. All those devices have the same primary address (pad) of 14 and no secondary addrss. They have a way to modify in advance their pad. However: 1. If I did not modify the pad of those devices and left all of them with 14, what would happen if I issue an ibdev() in my application? will it return an error or there will be an attempt to open one of the devices? The second option would be excelent as immediately after openning any device with this pad, I could issue an ibpad() to change it's pad to any other address except 14, but logically I believe the first option will happen. 2. Is there a way for the application to obtain the pad of any device connected to the gpib board _before_ openning this device thru ibdev() or ibfind()? Is there any function that does this or should I manually input this pad either to the application or to the gpib.conf file? 3. If I want to open a device using ibfind() thru it's name as entered in the gpib.conf file, am I free to give whatever name to each device or is there a limitation for this name to match something related to the device? I hope my questions are clear, thanks, Rafi. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.15.26/600 - Release Date: 12/23/2006 4:47 PM
FW: linux-gpib driver and select mechanism
-Original Message- From: Rafi Cohen [mailto:[EMAIL PROTECTED] Sent: Monday, December 18, 2006 12:45 PM To: [EMAIL PROTECTED] Sourceforge. Net Subject: linux-gpib driver and select mechanism Hi, if my application listens both to rs232 and gpib, is it possible to use the select mechanism with the linux-gpib driver? May I treat the device descriptor returned by ibdev() like any other file descriptor and use it with FD_SET, for example? Thanks, Rafi. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.15.26/598 - Release Date: 12/22/2006 3:22 PM
FW: primary address of devices
Hi list, I hope the following is not too offtopic and if it is, feel free to answer privately. Does anybody happen to know or work with linux-gpib driver? you may find details on http://linux-gpib.sourceforge.net. Ive sent the following 2 messages to the linux-gpib-general mailing list, but nobody answered me up to now. I hope somebody on this list may help me. I forward this message and another one, relating to 2 different subjects. Thanks, Rafi. -Original Message- From: Rafi Cohen [mailto:[EMAIL PROTECTED] Sent: Monday, December 18, 2006 1:08 PM To: [EMAIL PROTECTED] Sourceforge. Net Subject: primary address of devices Hi, sorry in advance if some of my questions are too basic and even not logic. My application needs to support connecting up to 30 devices (actually gsm simulators) to the gpib board in the computer. All those devices have the same primary address (pad) of 14 and no secondary addrss. They have a way to modify in advance their pad. However: 1. If I did not modify the pad of those devices and left all of them with 14, what would happen if I issue an ibdev() in my application? will it return an error or there will be an attempt to open one of the devices? The second option would be excelent as immediately after openning any device with this pad, I could issue an ibpad() to change it's pad to any other address except 14, but logically I believe the first option will happen. 2. Is there a way for the application to obtain the pad of any device connected to the gpib board _before_ openning this device thru ibdev() or ibfind()? Is there any function that does this or should I manually input this pad either to the application or to the gpib.conf file? 3. If I want to open a device using ibfind() thru it's name as entered in the gpib.conf file, am I free to give whatever name to each device or is there a limitation for this name to match something related to the device? I hope my questions are clear, thanks, Rafi. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.15.26/598 - Release Date: 12/22/2006 3:22 PM
FW: this may sound somewhat off-topic, but please read
Hi, after I sent a message to Ira answering his questions tome, I noticed that he sent his message to the list. So, I'm forwarding my answers as sent to him. Rafi. -Original Message- From: Rafi Cohen [mailto:[EMAIL PROTECTED] Sent: Sunday, December 26, 2004 3:20 AM To: Ira Abramov Subject: RE: this may sound somewhat off-topic, but please read Hi Ira, I need to correct you. With my braile display, I use vi and emacs very extensively. For mail reading, I use pine. concerning the quotes from previous mails, one of the buttons of the display brings me one line downwards without needing to read the entire line. So, I make use of the sign in the beginning of the quoted line, just read 2 or 3 words on each line to remember the text and go downwads until the current message's text and then read. So, it is not too slow. Rafi. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ira Abramov Sent: Sunday, December 26, 2004 2:10 AM To: linux-il@linux.org.il Subject: Re: this may sound somewhat off-topic, but please read Quoting Shaul Karl, from the post of Sun, 26 Dec: What is a braille display? I mean, how it looks, how the user interacts with it, how does it cope with something other then letters? If memory serves those interfaces display in Braille two or three lines of a terminal I'd assume it works like a dumb terminal and you use dumb terminal tools with it, such as ed mail rather than vi and mutt. In which case, I have to ask you, does it slow you a lot when people quote more than a line or two before they start their answer? I try to do this in my replies even without ever thinking about blind audience, because overquoting is annoying to me even as a seeing person, but I can only guess how it effects your readership... In particular, can't such a display automatically represent ASCII characters, without the need for a special driver? well, one WOULD need to have the installation all done on a serial console and without fancy menues... -- An almond in the rough Ira Abramov http://ira.abramov.org/email/ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
this may sound somewhat off-topic, but please read
Hello, I'm a software engineer and have some years of experience developping in the Unix/Linux environment, both as an employee and a freelancer. Since I always had a computer from the company with Linux already installed, I did not bother installing a Linux system on my home computer. Now, I want to install one, but there is a limitation for which I need your help. I'm a blind person and I'm using a braile display to interact with the computers. I can install the driver for the display after installing the system but I have no output during installation process and so I need a sighted assistance to do this. I live in Kfar Vradim and I'll most appreciate if someone will be ready to come over here and help me with this installation. I suggest to write to me offlist and we may fix an appropriate time. A second issue relating to this is that currently I'm searching for a new job. If somebody thinks that he may help me with this issue, please again write to me offlist and I'll give you the details of my experience and background. I take the opportunity to say that during just a week of membership in this mailing list, I'm enjoying the most proffessinal discussions and subjects and hope to contribute in the future when I''ll think my knowledge covers the scope of any specific discussion. Thank you all in advance, Rafi.
