|
You are right, now i wrote:
CFileDialog fd(TRUE, NULL, "*.txt", OFN_FILEMUSTEXIST | OFN_HIDEREADONLY);
fd.m_pOFN->lpstrTitle = "Carica file di osservazioni";
fd.m_pOFN->lpstrFilter = "Text files (*.txt)";
and it works great ! Thanx !
|
|
|
|
|
yes, i modified my previous post ; you could also have done this using the 5th parameter of the constructor...
also, don't hesitate to read the MSDN[^]. it's there for you !
|
|
|
|
|
The CFileDialog has on the bottom-right
corner a button labeled as "open".
How can i change the label into "save" ?
Thanx in advance,
Desmo16.
|
|
|
|
|
i am facing a problem with the socket class in win32. when trying to link windows and unix machines in win32 the unix machine not get the information as the sockets was closed for the threads which are finished .the recieving end just waits for all the threads to finish and only after all the threads finish the sockets was considered closed. is the socket class is blocking or non blocking type.
vineesh
|
|
|
|
|
Sounds like a problem with SO_LINGER. I do not think that has anything to do with blocking or non-blocking sockets.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Maybe this will help. From the SDK...
To assure that all data is sent and received on a connected socket before it is closed, an
application should use shutdown to close connection before calling closesocket. For example, to
initiate a graceful disconnect:
Call WSAAsyncSelect to register for FD_CLOSE notification.
Call shutdown with how=SD_SEND.
When FD_CLOSE received, call recv until zero returned, or SOCKET_ERROR.
Call closesocket.
Note The shutdown function does not block regardless of the SO_LINGER setting on the socket.
|
|
|
|
|
hi,
iam using the shut down there but it doesnt help. i want to send a successful packet before closing the socket . it was sent but after this point was the problem . if it was single thread it works properly .but when parrelel threads are there . it still makes problems.
vineesh
|
|
|
|
|
vinucv wrote: but when parrelel threads are there . it still makes problems
What is going on in these threads? As far as I know, sending from simultaneous threads is not
a good idea without synchronization. This may not be the case but I've never found documentation
that Windows Sockets is thread safe.
Are you destroying a thread while it's blocked on send()?
Are you closing the socket on one thread while another thread is blocked on send()?
The socket will be in blocking mode unless you've called WSAAsyncSelect or WSAEventSelect (this
could be different if you are using MFC socket classes).
|
|
|
|
|
Mark Salsbery wrote: As far as I know, sending from simultaneous threads is not
a good idea without synchronization.
Perhaps vinucv should be getting his fish filet from McDonalds 
led mike
|
|
|
|
|
!!!
|
|
|
|
|
the actual purpose of the code is a remote execution of programs.
i am trying to shedule windows programs in unix machines .
the failure case is only one
*)
suppose i am scheduling four parellel programs(PG1,PG2,PG3,PG4) .after the completion of first program (e PG1)i have to fire another program (PG5)
and only after the completion of all the parellel programs (PG1--PG4) another program PG6 has to be fired.All these programs are windows programs residing in windows machines.only the sheduling is done at the unix machine.
windows machines contains some agent programs for this and they are multithreaded. they send the details to unix serverand if program exists sends an exit status .this status should be read by unix machine and update the status in schedule.
suppose pg1 finishes first it will fire the program pg5 right?\
but it will not update the stauts to finish since the socket for the particular thread was not read as closed at unix .hence it has to wait for all the threads to finish and only after the programs pg1-pg4 are finishes
pg5 and pg6 are fired .
iam synchronized the threads and tried shutdowm with WSAAsyncSelect but all doesnt help.
vineesh
|
|
|
|
|
vinucv wrote: but it will not update the stauts to finish since the socket for the particular thread was not read as closed at unix
Is that the only way the unix side knows - by waiting for the socket to close?
Could you wait for the process to end on the Win32 side and send a message to the unix side
instead?
|
|
|
|
|
iam sending an exit status to unix machine it will read this and should update the status . but it willl still waiting for signals from the socket
and when the final thread finishes. it find the socket closed and then update .
even i totally confused....
vineesh
|
|
|
|
|
vinucv wrote: ...but it willl still waiting for signals from the socket...
What kind of signals?
If you have no control over the unix side then I can't think of anything you could do.
I mean, if the unix side does nothing until the socket is closed then how else can you notify the
unix side except by closing the socket?
|
|
|
|
|
vinucv wrote: and tried shutdowm with WSAAsyncSelect
what are you talking about, to shut down a socket you use shutdown[^]? 
led mike
|
|
|
|
|
in order to initiate a graceful disconnect:
i
Call WSAAsyncSelect to register for FD_CLOSE notification.
Call shutdown with how=SD_SEND.
When FD_CLOSE received, call recv until zero returned, or SOCKET_ERROR.
Call closesocket.
the socket was closed while testing but the unix machine doent notice it untill all the threads finished and close their sockets .
vineesh
|
|
|
|
|
As an experiment try this
call shutdown with SD_BOTH
call close
led mike
|
|
|
|
|
led mike wrote: As an experiment try this...
And then we'll all meet at McDonalds!!
|
|
|
|
|
And bring plenty of life vests for those that might need them!
led mike
|
|
|
|
|
|
Thanks All .........
nothing happens with the normal procedures and atlast i can send another signal to the unix server the socket was closed......
and it works
thank you once more
vineesh
|
|
|
|
|
when programming a cshell in vc++ i have to handle pss_thru in hyperthreading
help me to know how this pass_thru function is handled in hyperthreading.
vineesh
|
|
|
|
|
Please provide details on this pass_thru thingy. Function, Event, etc.
For the trivial case, HT cores can be treated as "real" processors. However, if you are doing someting that really needs the performance, you need to understand how and when they will have to wait on each other (on the same die).
It becomes more of a concern when dealing with systems that have multiple Hyperthreaded CPU cores, because how you spread out work across the virtual CPUs can make a difference in performance.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
James R. Twine wrote: It becomes more of a concern when dealing with systems that have multiple Hyperthreaded CPU cores, because how you spread out work across the virtual CPUs can make a difference in performance.
Hey James,
By default does the system (Win32) handle this for you or is it something that always has to
be explicitly done?
By "default", I mean using ::CreateThread() with normal priority and not changing affinity mask
or anything.
Thanks!
Mark
|
|
|
|
|
By just calling ::CreateThread(...) on any multicore/HT system will not allocate the thread to a particular CPU/Virtual-CPU. Normally, this is OK. However, if you want to ensure that two threads are not waiting for a particular CPU resource, you can set the affinity (or if you want to restrict what CPUs it can run on).
HT's virtual-CPUs are not real CPUs (and this comes from memory from a year or so ago) - they share a single execution engine on the die - this means that HTs compete for a shared resource on the die.
They each have their own copy of an "architectural state" (like registers) but they cannot really execute (or dispatch) executions at exactly the same time. They can decode and retire instructions independently of one another, IIRC, and this part provides a performance increase. It still does not beat out a real multi-core system, all things being equal.
When dealing with this on a multi-HT-CPU system, you need to allocate threads to every other CPU so that each thread ends up on its own die. (IIRC, the virtual CPUs are allocated in order of the dies in Win32, so if you have two HT CPUs in your system, you see 4 CPUs, and CPUs 0 and 1 are on the first die/chip and 2 and 3 are on the second die/cip. By allocating two threads to CPUs 0 and 2, they will run on different dies and thus can really execute independently and not compete for an on-die resource.
I do not think that Windows is smart enough to do this on its own (or at least, it was not before - it might be better now), this is why some applications (even properly multithreaded ones) did not run so great on the early HT processors - the OS treated them like real CPUs.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
